As noted in #3186934: Introduce an ExceptionHandler class in the database API, deprecate Connection::handleQueryException, the way query classes are loaded by Connection is preventing static code analysis, besides being 'a magic' in the sense that they're autoloaded by placing files that override the base classes in the same directory where the Connection class resides.
Part of #1921152: META: Start providing tour tips for other core modules.
Write tour integration for People admin page
Create tour yml files for required admin screens in admin/people.
Create patch for tour integration for primary People page
New tours
None
See: https://drupal.org/node/1921152#tour-tips-tech-note for tech notes on making tour tips.
It's more useful to show the user what they are typing instead of asking them to type it twice:
http://www.lukew.com/ff/entry.asp?1653= (2012)
http://www.lukew.com/ff/entry.asp?1941 (2015)
Add a password field with show/hide functionality and make it an option to use this instead of the password_confirm field
The password confirmation field can be removed and replaced with a show/hide link
Please don't commit this without signoff from an accessibility maintainer - @mgifford or @andrewmacpherson
| Issue category | Feature because usability improvement |
|---|---|
| Issue priority | Not critical because usability improvement |
| Unfrozen changes | Unfrozen because it only changes CSS/markup |
| Prioritized changes | The main goal of this issue is usability |
FilterPermissions uses a render array to mimic the styling of a warning instead of using a warning directly
None
In NodeViewsData::getViewsData(), $data['node_field_revision']['langcode']['help'] is set twice.
$data['node_field_revision']['langcode']['help'] = $this->t('The language the original content is in.');
$data['node_field_revision']['table']['wizard_id'] = 'node_field_revision';
$data['node_field_revision']['status']['filter']['label'] = $this->t('Published');
$data['node_field_revision']['langcode']['help'] = $this->t('The language of the content or translation.');
$data['node_field_revision']['link_to_revision'] = [
'field' => [
'title' => $this->t('Link to revision'),
'help' => $this->t('Provide a simple link to the revision.'),
'id' => 'node_revision_link',
'click sortable' => FALSE,
],
];
Remove one of the lines setting $data['node_field_revision']['langcode']['help'] .
Second step of #3215870: Require Composer 2.2 for Drupal 10.
From @longwave:
I think we should bump composer/installers to ^2.0. Reasoning:
- it is only listed in our root composer.json, not core's composer.json, so it is only used by core developers
- the backward incompatible changes do not affect us (minimum PHP requirement, removal of some unrelated frameworks; see https://github.com/composer/installers/releases/tag/v2.0.0)
We also include composer/installers in the recommended and legacy project templates.
There is also the interesting note
As of Composer 2.1, the Composer\InstalledVersions class has a getInstalledPackagesByType method which can let you figure out at runtime which plugins/modules/extensions are installed.
It's likely a long way off but in a Composer-only world we could perhaps use this for module discovery.
TBD
N/A
TBD
N/A
Needed.
Right now the Update module will always recommend the latest version in the current major that is installable, meaning published, secure, in a supported branch and support itself.
though there are some bugs, like #3227518: Never show a "Not supported!" version as "Recommended"
This is going to be problem for Automatic Updates when it is in core because the MVP will only support patch release not upgrading to different minor. see #3252187: Deal with core Update module recommending the latest release in the major version not the latest in the Minor version
For example if:
I am setting to major priority because this blocks the core Auto UPdates initiative from being able to recommend patch releases for any sites that are on a support minor that is not the most recent. Therefore it would stop Auto Updates from enabling cron automatic updates for a year on 1 branch
This also stops any site that is on the current minor from knowing about any patch release except the most recent. So if we restrict cron updates to only 1 patch level update at a time if you fell behind for some reason cron would not be able to get you to the latest patch release by updating incrementally over multiple cron runs.
currently based on https://updates.drupal.org/release-history/drupal/current
If a site where on 9.1.13 the Update would not recommend 9.1.14. It would recommend 9.2.10. You can test by faking the drupal version Drupal.php
in the long term it would be good if the Update module recommend a version in the current minor and then in any other minor that is supported(for core that will usually be 2) in the same major. But this will major need refactoring of the Update reports.
For now we should simple change update_calculate_project_update_status() to store all the info about installable releases in $project_data which it modifies. This will allow other modules like Automatic Updates in contrib and in the core version which should be started soon to pick a version in the current minor that we know is secure and supported.
update_calculate_project_update_status() already has all the information it needs to do this.
Media in CKEditor4 has an edit media
which let's user choose the view mode. This is not yet available in CKEditor 5.
This will allow us to port:
\Drupal\Tests\ckeditor5\FunctionalJavascript\MediaTest::testViewMode()\Drupal\Tests\ckeditor5\FunctionalJavascript\MediaTest::testDialogAccess()Note that ideally, we would not use a Drupal dialog for this, and instead implement it on the client side, much like #3246385: [drupalMedia] Support captions on <drupal-media> for captioning and alignment.
TBD
This issue is part of the composer initiative: #2958021: Proposal: Composer Support in Core initiative
The vendor cleanup scripts were moved into a Composer plugin in #3057094: Add Composer vendor/ hardening plugin to core. This is a follow-on issue to that task.
The original sanitization scripts still exist in the repository at Drupal\Core\Composer\Composer::vendorTestCodeCleanup(), and are called as an event script in drupal/drupal's composer.json like this:
"scripts": {
"post-package-install": "Drupal\\Core\\Composer\\Composer::vendorTestCodeCleanup",
"post-package-update": "Drupal\\Core\\Composer\\Composer::vendorTestCodeCleanup",
These scripts are now deprecated, and should be removed.
Once the deprecated scripts are no longer being called, they should be removed. There are three potential places where these scripts may be called:
The first set of calls will be removed by #2982680: Add composer-ready project templates to Drupal core. When the Drupal template projects are created, they will use the new Vendor Hardening plugin rather than the cleanup scripts. Once tarballs are generated from the template projects, the scripts will be unused in tarball-based sites (managed via `drush pm-update` etc.).
The second use-case is Drupal core development. To stop using the scripts during core development, the Vendor Hardening plugin will need to be added as a "path" repository of the root-level composer.json file of drupal/drupal, and the references to the scripts in the "scripts" section will need to be removed. This work can be done as part of this issue.
The final place where these scripts may be called is from external sources, e.g. community-managed Drupal template projects. These cleanup scripts are not needed for Drupal sites that utilize a relocated document root, so drupal-composer/drupal-project, for example, does not call these scripts. At the moment, there are no known examples of external projects that use these scripts. If there are any that exist, then this work cannot be done until Drupal 9.
Decide on the timing of when to do this work.
None.
None.
None.
tbd
The submit function Drupal\Node\NodeForm::save() does not return a value. According to it's interface it should.
See https://api.drupal.org/api/drupal/core!modules!node!src!NodeForm.php/fun...
Save the return code from `$node-save() and pass it back to the caller
Coding - add tests, that verify the behaviour
none
No changes - adjusting real behavior to documented API.
none
After enabling the 'Account administration pages' setting at /admin/config/regional/language/detection,
there are cases where \Drupal::routeMatch()/ return a NullRouteMatch
At this point, if you debug the function of the classProductVariationAccessControlHandler::checkCreateAccess()
You'll see that the variable $product = \Drupal::routeMatch()->getParameter('commerce_product');
Is null, because the RouteMatch itself is a NullRouteMatch.
This doesn't happen if the 'Account administration pages' isn't active, or it has less priority of the URL in the 'Interface text language detection' option list. However, the latter case ins't a good solution: if the URL detection has priority over the 'Account administration pages` the latter has pretty much no use.
I have used the Commerce issue in the explanation on how reproduce because it is a real case where it is happening, but I believe it could happen in other situations too.
User ID from logged in user default argument for views contextual filter, right now is getting from \Drupal::curentUser(); global class instead of dependency injection to get AccountProxy object of current user.
Add dependency injection to the Drupal\user\Plugin\views\argument_default\CurrentUser class
Also, fix phpDoc.
drupal/core-recommended metapackage locks dependencies to the specific lockfile version of dependencies, as does the compiled vendor/ code in Drupal tarball installations. Furthermore, the site will not be able to resolve to secure dependencies if it is on an old PHP version. This means that even if core does implement a custom mitigation, the site may still be locked into running insecure code from an insecure dependency.MINIMUM_PHP prevents Drupal sites from installing any Drupal updates at all unless they also increase their platform PHP version accordingly. This is extremely disruptive and dangerous, especially if it happens on a security window. Many site owners found it too disruptive even in a minor release of Drupal core.\Drupal::MINIMUM_SUPPORTED_PHP was introduced in #3039287: Implement changes required to remove support for PHP 5.5 and 5.6, to allow sites to be updated on old PHP versions, but still warn them that the PHP version was too old.
Drupal 9 requires PHP 7.3 or higher, and the version requirement for Apache has been increased to Apache 2.4.7 or higher.
\Drupal::MINIMUM_SUPPORTED_PHP to warn on installation (rather than erroring) the same as it does on update, since various site update/deployment workflows use installation from default config.\Drupal::MINIMUM_SUPPORTED_PHP to at least 7.4 in Drupal 9.4.\Drupal::MIINIMUM_SUPPORTED_PHP is increased to at least 7.4and possibly later 8.0 (see the proposal in #3261447: Add an API for dynamically setting recommended and supported PHP versions based on known and predicted PHP release schedules).Then:
See #3261606: Provide more specific messaging about the consequences of using an unsupported PHP version for specific implementation details of what we would do in this circumstance.
Needs followup per #108 for Drush.
An informational status report message is displayed:
There are no warnings on installation or update
A warning is displayed on the status report, informing the user that their version of PHP is too old:
The same warning is displayed in the installer:
To advance to the next screen of the installer, they have to scroll to the end of the page and click a small "continue anyway" link.
No warning is displayed yet when using the quick-start command or drush si; those would be handled in followups.
The same warning is displayed when running update.php:
A similar message is displayed when running drush updb:
[ayrton:drupal_test_site | Sat 20:27:59] $ vendor/bin/drush updb
[warning] Your PHP installation is too old. Drupal requires at least PHP /7.4.0/. It is
recommended to upgrade to PHP version /8.0/ or higher for the best ongoing
support. See PHP's version support documentation [1] and the Environment
requirements of Drupal 9 [2] page for more information.
[1] http://php.net/supported-versions.php
[2] https://www.drupal.org/docs/9/how-drupal-9-is-made-and-what-is-included/environment-requirements-of-drupal-9#s-php-version-requirement
(Currently using PHP 7.3.33
)
In #3261452: Remove tracker module from core the quickedit module is going to be removed from core in 10.x. help_topics Is an experimental module which contains topics related to quickedit module.
Move the tracker topics about quickedit from the help_topics module.
Since there's already a Contrib version of the quickedit module, the moved help topics should be added to that module as well. I've created #3264949: [PP-1] Move quickedit help topics to Contrib quickedit module to do just that.
The actual removal of the quickedit-related help topics from core will take place in #3227033: [PP-3] Remove quickedit from core where currently the remove-quickedit-from-core-in-D10 patch lives.
To rename the module to "actions UI" migrations should be moved to system module because entity defined exactly there
\Drupal\action\Plugin\migrate\source\Action should be moved to system or migrate_drupal because the action entity defined in system module and module will be renamed to provide UI just to configure actions
get agree on move (keep BC)
patch & commit
no
plugin and some classes will be moved
If you are attaching some option attributes to a link field (using a custom module for example), those attributes are removed on node save.
One solution is to use link_attributes, but you might not want to allow users to edit those attributes from node edit.
In #3194084: Support functionality equivalent to ckeditor_stylesheets, several improvements to ie11.filter.warnings.es6.js were identified that would provide the same functionality with simpler code. However, those improvements were out of scope so they'll happen here instead.
Reviewing the changes in the MR is likely easier than converting the solution to prose.
The default action on /admin/content is "Delete selected content". It's really easy to push "Apply" button by mistake, thinking it will apply the filter, because of the button title, and because it's positioned at the bottom of the form, typically where people expect to look for submit buttons. (This actually happened to me today, and I've been using Drupal for 8 years)
See screenshots.
Initially, adding a weight to action config entities has been tried. However, as is mentioned in #152, this is not the correct approach as an action (read a config entity) may appear on several views and the site builder may need different sort orders on each view. Read the #152 comment for more background.
None.
Before:
The checkboxes let you select which actions will be available, but you cannot control the order.
After:
The form element used to select the actions is converted from checkboxes to draggable table. The table allows both, actions selection and action reordering.
The actions are reordered for new sites on /admin/content, /admin/content/comment, /admin/content/comment/approval, /admin/content/media with the "Delete" action as last option.
Before:
After:
None.
New actions_order option for Bulk Form handler.
Use drag and drop in Views bulk form field configuration form to define order which will be used to expose the actions in the bulk forms.
The array of Views table data has a special 'table' key for each table which contains metadata about the table.
For entity tables, this has additional properties. One of these is the 'entity revision' property, which is a boolean that says whether this table is for revisions or not.
The EntityViewsData default handler sets this on the entity tables:
$data[$data_table]['table']['group'] = $this->entityType->getLabel();
$data[$data_table]['table']['provider'] = $this->entityType->getProvider();
$data[$data_table]['table']['entity revision'] = FALSE;
...
$data[$views_revision_base_table]['table']['entity revision'] = TRUE;
$data[$views_revision_base_table]['table']['base'] = [
However, it fails to set this property for the revision table itself.
This is a problem because QueryPluginBase::getEntityTableInfo() assumes that any table that is an entity table has this set:
if (isset($base_table_data['table']['entity type'])) {
$entity_tables[$base_table_data['table']['entity type']] = [
'base' => $base_table,
'alias' => $base_table,
'relationship_id' => 'none',
'entity_type' => $base_table_data['table']['entity type'],
'revision' => $base_table_data['table']['entity revision'],
];
This causes an error if a Views relationship goes to the revision table, as the revision table becomes one of the joined base tables, and the code above runs for it, and finds that $base_table_data['table']['entity revision'] is not set.
Meeting will happen in #d10readiness on drupal.slack.com.
Hello and welcome to this Drupal 10 readiness meeting!
This meeting:
➤ Is for core and contributed project developers as well as people who have integrations and services related to core. Site developers who want to stay in the know to keep up-to-date for the easiest Drupal 10 upgrade of their sites are also welcome.
➤ Usually happens every other Monday at 19:00 UTC.
➤ Is done over chat.
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to: `https://www.drupal.org/project/drupal/issues/3259755`
➤ *Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.:zero: Who is here today? Comment in the thread below to introduce yourself.
:one: Do you have suggested topics you are looking to discuss? Post in this thread and we'll open threads for them as appropriate.
:two: TBD