Andrew Macpherson writes:
The hidden text of the edit and remove buttons for an embedded media item should probably include the label of the item, to be more screen reader-friendly.
↧
Edit Media button within WYSIWYG should include media label for screen readers
↧
Missing translations revisions
Since September in our site some nodes are disappearing. We had 8.5.X but now we have latest core version 8.6.2.
We have multilingual site and there are more than 10 persons adding and editing content and the same time.
Content that have problems: is translatable and working with revision system.
We have seen that node_field_data, node__body and other node field registers are deleted, but they are in revision tables.
No logs and no errors in watchdog, no deleting actions from editors, only disappear "node data" from database but not "node revision data".
What are the steps required to reproduce the bug?
We don't know why this happens and how to reproduce. Things to be in mind:
- Only happens in office hours, maybe problem is related with multiples access and same time.
- Only happens in content with a lot of editions, we have old content types with a lot of nodes with no problems.
- Only happens with translation entity, never happened with source translation.
We use following sql code to get orphans revisions:
SELECT distinct nfr.nid, nfr.langcode, nfr.vid
FROM node_field_data nfd
LEFT JOIN node_field_revision nfr ON nfd.nid = nfr.nid
where nfd.langcode != nfr.langcode
AND nfr.langcode NOT IN (
SELECT nfd2.langcode
FROM node_field_data nfd2
WHERE nfd2.nid = nfd.nid
)
AND nfr.vid = (
SELECT nfr2.vid
FROM node_field_revision nfr2
WHERE nfr2.nid = nfr.nid
AND nfr2.langcode = nfr.langcode
ORDER BY nfr2.vid DESC
LIMIT 0,1
)
ORDER BY nfr.nid DESC;We have checked crons, code, a lot of process and we didn't get anything.
We have tried changing php max_input_vars to 3000 too but with no luck.
Any ideas?
↧
↧
'Is not equal to' operator ignored on exposed, grouped filter
Problem/Motivation
In a view, for an exposed, grouped filter, the specified operator is apparently ignored.
Steps to reproduce:
- a clean install of 8.7.6
- in /admin/structure/views/settings, turn on Show the SQL query (you need to tick 'Show information and statistics about the view during live preview' first, which is a bit of a UX issue in it's own right, imho)
- then edit the Content view (views.view.content)
- edit the Content: Published filter (labelled 'Published status')
- change the second grouping (Unpublished) from: 'is equal to no' to: 'is not equal to yes'
- test each value of the dropdown using the Preview, examining at the SQL query
Expected:
selecting Unpublished and pressing Filter should give a query fragment of:
WHERE (node_field_data.status != '1') AND …
Observed:
WHERE (node_field_data.status = '1') AND …
(similarly, if you set it to 'is not equal to no', you still get: node_field_data.status = '0')
Proposed resolution
Remaining tasks
- Is this a duplicate of another bug? (I did a cursory search)
- Establish cause.
- Write patch.
User interface changes
none
API changes
none expected
Data model changes
none expected
Release notes snippet
↧
Convert path alias migrations to create entities
Problem/Motivation
In #2336597: Convert path aliases to full featured entities, we convert path aliases to entities. Once that issue lands, we should update the migrations in the Path module to use entity:path_alias as the destination plugin instead of the custom url_alias.
Proposed resolution
Update migrations/d6_url_alias.yml and migrations/d7_url_alias.yml in the Path module. Change the destination key as noted and make any related changes that this requires.
Remaining tasks
- Review the patch.
User interface changes
None.
API changes
None.
Data model changes
None.
↧
Convert EntityTest to use EntityOwnerTrait
Problem/Motivation
Follow up to #2949964: Add an EntityOwnerTrait to standardize the base field needed by EntityOwnerInterface.
The EntityTest entity should use EntityOwnerTrait.
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
↧
↧
make exposed filter of parent group have name not id
I have a relationship in my view to the content group content, and then I put in an exposed filter for the parent group. But the exposed filter works with the id of the group, I want it to work with a drop down of the name of the group . how can I achieve this?
↧
Workflows does not work with translation
Hi ,
I am using this module in one of my project and that site is multilingual. So what is happening if i am changing state of node for uk region then it automatically apply for en region as well which should not happen . Due to which i am facing lot of problem.
My drupal core version is 8.7.1
Workflow module version :- 8.x-1.1 (It is in Core itself ;) )
Thanks
↧
D7 - Visiting index.php should redirect to install.php if settings.php already has database credentials but database is empty.
original D8 issue: #728702: Visiting index.php should redirect to install.php if settings.php already has database credentials but database is empty.
Problem/Motivation
If the user visits the site index for a Drupal site that has database credentials in settings.php but has not yet been installed completely, the user will receive a fatal error that does not in any way indicate that the user should visit install.php to complete the installation.
Proposed resolution
Detect an empty database during bootstrap, and redirect to install.php if installation is not already in progress.
Patch in #728702-17: Visiting index.php should redirect to install.php if settings.php already has database credentials but database is empty. is confirmed to resolve this issue for both D7 and D8.
see patch in this issue rerolled from #728702-36: Visiting index.php should redirect to install.php if settings.php already has database credentials but database is empty.
Remaining tasks
None.
User interface changes
User will be redirected to install.php if there is a database configuration but the database is empty.
API changes
None.
Original report by @arpeggio
The setup are:
-database empty
-drupal updated from CVS
-set the C:\xampp\htdocs\sites\sites.php with $sites['localhost'] = 'kapitbisig.com';
-manually populated the the database credentials in C:\xampp\htdocs\sites\kapitbisig.com\settings.php
I got the following error message when I browsed http://localhost
Fatal error: Call to undefined function _system_rebuild_theme_data() in C:\xampp\htdocs\includes\theme.inc on line 586
↧
Allow passing context information to media_oembed_iframe theme implementation.
Problem/Motivation
To enable more control over the html returned by an oembed provider, more optional contextual information in the theme implementation media_oembed_iframe would be useful (e.g. to enable autoplay for videos from YouTube, if a field formatter setting is set).
Proposed resolution
To enable modules to add contextual information to the iframe, the OEmbedIframeController should pass a "context" query argument to the render array.
To easily add context based on the provider or field formatter, an additional alter hook for the iframe usage should be added.
Remaining tasks
Review of the attached patch.
User interface changes
None
API changes
Additional alter hook for contextual information in the formatter.
Data model changes
None
↧
↧
Running single phpunit tests doesn't work
Problem/Motivation
https://www.drupal.org/docs/8/phpunit/running-tests-through-command-line... - here is presented notation for running single phpunit tests: php core/scripts/run-tests.sh --browser --verbose --url http://example.com/ --class "Drupal\module_name\Tests\TestClass::testMethod". Unfortunately it doesn't work since tests moved into phpunit. What happens is that Drupal\module_name\Tests\TestClass::testMethod is not recognized as a TestCase class here: https://git.drupalcode.org/project/drupal/blob/8.8.x/core/scripts/run-te... . Which makes it being run as a simpletest test, which ultimately ends in a failure, because of the different "run" method declaration.
Proposed resolution
Proposed resolution is in the patch, that will be following shortly.
Remaining tasks
Review the patch.
↧
ViewsEntitySchemaSubscriber does not update views base table when making an entity type translatable
Problem/Motivation
I'm currently in the process of making an entity type translatable through an update. That entity type has views. I noticed that the view does a very nice job of updating the table of all the field, sort, relationship, ... handlers but it doesn't update the base table, so the result is a completely broken view.
Proposed resolution
Similar to baes table rename, update the base_table in the view.
Remaining tasks
Pretty sure that this won't work for revision views and the logic there in general might not work, as it would need to use different table mappings. I think that could be a separate issue.
User interface changes
API changes
Data model changes
↧
Provide a way for fields with computed or custom storage to decide how to impact entity queries.
Problem/Motivation
It is not possible use Entity Query to filter nodes with content moderation module enabled.
When I debug a node with this config enabled, I cant find a field with this value.
$query = \Drupal::entityQuery('node')
->condition('type', 'article', '=')
->condition('moderation_state', 'archived', '=');
$nids = $query->execute();But here it works
$node = Node::load($nid);
$node->get('moderation_state')->getValue();Proposed resolution
Find a way that we can add a condition to filter content with EntityQuery by moderation_state field.
↧
Core version key in module's .info.yml doesn't respect core semantic versioning
Problem/Motivation
Drupal modules and themes need to be able to specify that they depend on specific versions of Drupal because a new minor version of Drupal may introduce new APIs and a patch version may fix bugs. Drupal modules and themes also should be able to specify if they are compatible with 2 major versions of Drupal such as 8 and 9, if they don't use any APIs that will be removed in Drupal 9. Modules, install profiles and themes should not have to create a new major branches to achieve this as per #2608062: [META] Requirements for opening the Drupal 9 branch.
For Drupal 8 projects, currently the core key in info.yml files only supports core: 8.x which denotes that they support any version of Drupal 8. To get around this limitation many modules use the dependencies: key in info.yml files with a more specific version of system module. For example- "drupal:system (>8.6)". But this method is not enough because it does not support patch releases either, see #2641658: Module version dependency in .info.yml is ineffective for patch releases.
While we could change the core: key to accept semantic version constraints to allow requiring specific core patch versions, for example core: ^8.7, or even support multiple branch compatibility (core: ^8 || ^9), or both (core: ^8.7 || ^9) this would cause problems for any sites using previous versions of Drupal 8 core, if they attempted to update a module they currently have installed that switched to the new format.
A Drupal 8.7.5 site that has my_module 8.x-1.1 that uses core: 8.x and then updates to my_module 8.x-1.2 that uses core: ^8 (anything beside 8.x) will have this this module silently disabled, even while the configuration for the module would still be available. There would be no message that this happened. See #138 and #2917600: Disabling missing modules results in a "Unable to install MODULE already exists in active configuration" warning or PreExistingConfigException (via Drush).
Proposed resolution
As a consequence of the above, we need to introduce a new key core_version_requirement: (better name?) that would accept Composer semantic version constraints. The version constraints will be evaluated by \Composer\Semver\Semver::satisfies(). The rules for this can be found at https://getcomposer.org/doc/articles/versions.md.
This key could be used at the same time as the core: key. But in certain cases it would be used in place of the core: key. For example assuming this issue gets committed to 8.8.x, the following combination would not produce the expected results info.yml file:
core: 8.x
core_version_requirement: ^8.8
This would not actually restrict anyone from installing it on Drupal 8.7.1 since the core_version_requirement key would be ignored and would therefore still allow the module to be installed. We cover this case by not allowing the core: key once a core_version_requirement key requires Drupal 8.8 or later. Not having the core: key will give a hard fail in Drupal 8.7.x sites but because it fails in \Drupal\Core\Extension\InfoParserDynamic::parse this would not cause a problem in #138 and #2917600: Disabling missing modules results in a "Unable to install MODULE already exists in active configuration" warning or PreExistingConfigException (via Drush).
Another combination that would not produce the expected results:
core: 8.x
core_version_requirement: ^8.7.4
In this case Drupal 8.7.3 would not enforce core_version_requirement: ^8.7.4. We enforce this by not allowing restrictions that cover versions before this issue is committed because these will not actually be enforced.
In both these cases it would be hard for a contrib author to be aware for these problems if they are working on Drupal 8.8.x unless they also tested their module on previous versions of Drupal. Therefore add validation to \Drupal\Core\Extension\InfoParserDynamic::parse() to make sure that module authors don't these problems.
Examples of supported core_version_requirement: values:
core_version_requirement: value | Evaluates to constraints | Comments |
|---|---|---|
| ^8.8 | >= 8.8.0.0-dev < 9.0.0.0-dev | Recommended for modules that are only compatible with 8.8.x and above but not 9. |
| ^8 || ^9 | >= 8.0.0.0-dev < 10.0.0.0-dev | Recommended for modules that are compatible with both Drupal 8 & 9. Most modules aren't actually compatible with all versions of Drupal if removed deprecated API use and used the new replacements. |
Remaining tasks
- Determine whether there is better name than
core_version_requirement - Determine if this should be backported to 8.7
\Drupal\Core\Extension\InfoParserDynamic::FIRST_CORE_VERSION_REQUIREMENT_SUPPORTED_VERSIONwill have to be updated accordingly
User interface changes
Small string change for modules page.
API changes
Support core semantic versioning for Drupal core via new core_version_requirement key.
Data model changes
None.
Release notes snippet
A new core_version_requirement has been added to info.yml files. This key replaces the core key for projects that only support Drupal 8.8 onwards (including Drupal 9). It may be used in addition to the core key for projects that want to specify compatibility with Drupal 9 as well (but remain compatible with prior versions of Drupal 8). Read more at https://www.drupal.org/node/3070687
↧
↧
REST views: double encoding of apostrophes in REST Export display
In the below sample of a REST export view output in JSON format, you can see that an apostrophe character (ASCII code 39) is double encoded in the form of "\u0026#039;".
[{"book_background_pattern":"\/sites\/default\/files\/a_visit_to\/background_images\/avt_s18_background_pattern.jpg","cover":"\/sites\/default\/files\/a_visit_to\/background_images\/avt_doc_S18_cover.jpg","dark_color":"0073b9","accent_color":"a92825","light_color":"c7d5ee","header_background":"\/sites\/default\/files\/a_visit_to\/background_images\/avt_s18_header.png","title":"The Doctor\u0026#039;s Office: A 4D Book","vuforia_device_database":"\/sites\/default\/files\/a_visit_to\/doctors_office\/targets\/a_visit_to_doctors_office.zip","id":"8799","author":"Blake A. Hoena","illustrator":"","series":"A Visit to...","series_id":"268"}]
Steps to reproduce:
- Create a node with a title containing an apostrophe character.
- Create a view containing a REST Export display.
- Set the view format to "Fields."
- Add the "Content:Title" field to the field list.
- Preview the results of the view.
- Observe that the apostrophe character is double encoded.
↧
OEmbed video migration: Call to a member function mainPropertyName()
We are migrating youtube links from D6 link fields to D8 remote video media entities. Prior to that, we successfully migrated a D6 image node-type to image media entities without any issues. The video migration looks like this:
field_media_oembed_video: field_record_source/0/url
The migration fails with this error:
Error: Call to a member function mainPropertyName() on null in Drupal\media\MediaSourceBase->getSourceFieldValue() (line 336 of /var/www/docroot/core/modules/media/src/MediaSourceBase.php).
The underlying problem is that, in MediaSourceBase::getSourceFieldValue() the fields mainPropertyName() method is called even if the field is empty. I am not sure if the problem is really the MediaSourceBase::getSourceFieldValue() method or that the field itself returns the wrong value when it is empty, but I wrote a patch that checks if the field is empty before trying to call the fields mainPropertyName() method.
↧
[PP-2] Convert the path alias admin overview to a list builder
Problem/Motivation
After path aliases are converted to entities, we should be able to convert their custom admin overview to an entity list builder.
Proposed resolution
Do it.
Remaining tasks
See above.
User interface changes
Nope.
API changes
Nope.
Data model changes
Nope.
↧
[PP-1] Convert custom path alias forms to entity forms
Problem/Motivation
After path aliases are converted to entities, we should also convert their forms to extend content entity form base classes.
Proposed resolution
Convert custom path alias forms to entity forms.
Remaining tasks
Do it :)
User interface changes
Nope.
API changes
Nope.
Data model changes
Nope.
↧
↧
Ignore, testing issue
↧
Drupal\Component\Utility\UrlHelper::externalIsLocal should check for port numbers
Drupal\Component\Utility\UrlHelper::externalIsLocal should also check for differences in the port number in $url and $base_url. See the attached patch.
↧
Allow Symfony 4.4 to be installed in Drupal 8
Problem/Motivation
Drupal 9 will release with Symfony 4.4, see #3009219: Update Symfony to 4.4 in Drupal 9.0. In order to be able to do that, we should make Drupal 8 compatible with Symfony 4.4 first as much as possible. We cannot allow Symfony 4.4 to be installed from a simple composer update command, as current ways to install Drupal with composer would not protect production sites from switching to Symfony 4.4 which is unintended. That also means that until there is a Drupal 9 branch, there will be no easy way to test contrib with Symfony 4.4.
Proposed resolution
- Resolve and commit the remaining issues needed to make Symfony 4 pass tests.
- Provide a script or instructions on how to adjust the various
composer.jsonfiles for those adventurous souls who wish to try it with contrib, but it should not happen by default on a simple update.
Focus on Symfony 4.4 here. All Symfony 5 releated work is in #3055180: [META] Make Drupal 8 work with Symfony 5 (along with Symfony 3 and 4).
Remaining tasks
The following outstanding issues must be resolved to make the tests pass:
- A chromedriver test fail that is still being debugged.
User interface changes
None.
API changes
Symfony 4.4 API will be supported.
Data model changes
None
Release notes snippet
Drupal now supports Symfony 4.4.
↧