DROP TABLE IF EXISTS `watchdog`;
CREATE TABLE `watchdog` (
`wid` int(11) NOT NULL AUTO_INCREMENT COMMENT 'Primary Key: Unique watchdog event ID.',
`uid` int(11) NOT NULL DEFAULT '0' COMMENT 'The users.uid of the user who triggered the event.',
`type` varchar(64) NOT NULL DEFAULT '' COMMENT 'Type of log message, for example "user" or "page not found."',
`message` longtext NOT NULL COMMENT 'Text of log message to be passed into the t() function.',
`variables` longblob NOT NULL COMMENT 'Serialized array of variables that match the message string and that is passed into the t() function.',
`severity` tinyint(3) unsigned NOT NULL DEFAULT '0' COMMENT 'The severity level of the event; ranges from 0 (Emergency) to 7 (Debug)',
`link` varchar(255) DEFAULT '' COMMENT 'Link to view the result of the event.',
`location` text NOT NULL COMMENT 'URL of the origin of the event.',
`referer` text COMMENT 'URL of referring page.',
`hostname` varchar(128) NOT NULL DEFAULT '' COMMENT 'Hostname of the user who triggered the event.',
`timestamp` int(11) NOT NULL DEFAULT '0' COMMENT 'Unix timestamp of when event occurred.',
PRIMARY KEY (`wid`),
KEY `type` (`type`),
KEY `uid` (`uid`),
KEY `severity` (`severity`)
) ENGINE=InnoDB AUTO_INCREMENT=811 DEFAULT CHARSET=utf8 COMMENT='Table that contains logs of all system events.';

The website encountered an unexpected error. Please try again later.

Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[HY000]: General error: 1364 Field 'item_id' doesn't have a default value: INSERT INTO "queue" ("name", "data", "created") VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2); Array ( [:db_insert_placeholder_0] => update_fetch_tasks [:db_insert_placeholder_1] => a:6:{s:4:"name";s:6:"drupal";s:4:"info";a:6:{s:4:"name";s:14:"Automated Cron";s:7:"package";s:4:"Core";s:7:"version";s:6:"10.0.9";s:7:"project";s:6:"drupal";s:9:"datestamp";i:1683108678;s:16:"_info_file_ctime";i:1685262390;}s:9:"datestamp";i:1683108678;s:8:"includes";a:46:{s:14:"automated_cron";s:14:"Automated Cron";s:8:"big_pipe";s:7:"BigPipe";s:5:"block";s:5:"Block";s:13:"block_content";s:12:"Custom Block";s:10:"breakpoint";s:10:"Breakpoint";s:9:"ckeditor5";s:10:"CKEditor 5";s:7:"comment";s:7:"Comment";s:6:"config";s:21:"Configuration Manager";s:7:"contact";s:7:"Contact";s:10:"contextual";s:16:"Contextual Links";s:8:"datetime";s:8:"Datetime";s:5:"dblog";s:16:"Database Logging";s:18:"dynamic_page_cache";s:27:"Internal Dynamic Page Cache";s:6:"editor";s:11:"Text Editor";s:5:"field";s:5:"Field";s:8:"field_ui";s:8:"Field UI";s:4:"file";s:4:"File";s:6:"filter";s:6:"Filter";s:4:"help";s:4:"Help";s:7:"history";s:7:"History";s:5:"image";s:5:"Image";s:14:"layout_builder";s:14:"Layout Builder";s:16:"layout_discovery";s:16:"Layout Discovery";s:4:"link";s:4:"Link";s:17:"menu_link_content";s:17:"Custom Menu Links";s:7:"menu_ui";s:7:"Menu UI";s:5:"mysql";s:5:"MySQL";s:4:"node";s:4:"Node";s:7:"options";s:7:"Options";s:10:"page_cache";s:19:"Internal Page Cache";s:4:"path";s:4:"Path";s:10:"path_alias";s:10:"Path alias";s:6:"search";s:6:"Search";s:8:"shortcut";s:8:"Shortcut";s:6:"system";s:6:"System";s:8:"taxonomy";s:8:"Taxonomy";s:4:"text";s:4:"Text";s:7:"toolbar";s:7:"Toolbar";s:4:"tour";s:4:"Tour";s:6:"update";s:14:"Update Manager";s:4:"user";s:4:"User";s:5:"views";s:5:"Views";s:8:"views_ui";s:8:"Views UI";s:8:"standard";s:8:"Standard";s:7:"stable9";s:8:"Stable 9";s:5:"claro";s:5:"Claro";}s:12:"project_type";s:4:"core";s:14:"project_status";b:1;} [:db_insert_placeholder_2] => 1687605552 ) in Drupal\mysql\Driver\Database\mysql\ExceptionHandler->handleExecutionException() (line 43 of core\modules\mysql\src\Driver\Database\mysql\ExceptionHandler.php).
Drupal\Core\Database\StatementWrapper->execute(Array, Array) (Line: 44)
Drupal\mysql\Driver\Database\mysql\Insert->execute() (Line: 95)
Drupal\Core\Queue\DatabaseQueue->doCreateItem(Array) (Line: 68)
Drupal\Core\Queue\DatabaseQueue->createItem(Array) (Line: 125)
Drupal\update\UpdateProcessor->createFetchTask(Array) (Line: 288)
update_get_available() (Line: 38)
update_requirements('runtime') (Line: 96)
update_page_top(Array) (Line: 352)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}(Object, 'update') (Line: 388)
Drupal\Core\Extension\ModuleHandler->invokeAllWith('page_top', Object) (Line: 349)
Drupal\Core\Render\MainContent\HtmlRenderer->buildPageTopAndBottom(Array) (Line: 146)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
call_user_func(Array, Object, 'kernel.view', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.view') (Line: 168)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 74)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 686)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Problem/Motivation

Drupal core mail capabilities are stuck in the early 2000.

Steps to reproduce

Attempt to use mailhog (in development) or SMTP (in production).

Proposed resolution

As per symfony docs:

Symfony's Mailer & Mime components form a powerful system for creating and sending emails - complete with support for multipart messages, Twig integration, CSS inlining, file attachments and a lot more. Get them installed with:

Emails are delivered via a "transport". Out of the box, you can deliver emails over SMTP. Instead of using your own SMTP server or sendmail binary, you can send emails via a third-party provider.

Symfony mailer is maintained in the symfony framework repository. Like all symfony components it is available as a separate package as well.

As a pre-requisite of #1803948: [META] Adopt the symfony mailer component, add the symfony/mailer component as a composer dependency to Drupal core. Additionally make all supported symfony mailer transports accessible via a simple mail plugin which can act as a drop-in replacement for the existing php mail plugin.

The Symfony mime component doesn't support format=flowed soft wrapped text. Thus, mails sent with the Symfony mailer plugin may look slightly different in MUAs supporting soft wrapping compared to the ones sent with the default PHP mail plugin.

Manual testing instructions

With this patch in place (and composer dependencies installed), use the following drush command to switch the mail plugin:

drush config:set system.mail interface.default symfony_mailer

In order to configure the DSN, use the following command:

• For the default sendmail transport:
  drush config:set system.mail mailer_dsn sendmail://default
• For mailhog on localhost:
  drush config:set system.mail mailer_dsn smtp://localhost:1025
• For authenticated SMTP:
  drush config:set system.mail mailer_dsn smtp://user:pass@smtp.example.com:25

Remaining tasks

User interface changes

None.

API changes

None.

Data model changes

Add new config key mailer_dsn in system.mail.

Release notes snippet

Problem/Motivation

Currently in Drupal we have the old procedural hook system, we have symfony events, and we have tagged services and service collectors, to allow different modules or components broadcast or respond to "events" (in the broader sense).

The procedural hook system has a number of problems and limitations (some already mentioned in #2237831):

• Possibility of name clashes / ambiguity, e.g. "field" + "_group_permission" vs "field_group" + "_permission".
• No dependency injection: Hook implementations have to call \Drupal::service(...) to get their dependencies.
• Most implementations are in *.module files, which can get crowded, make it hard to organize code, and can easily cause git merge conflicts, if multiple branches attempt to add new hook implementations.
• There can be only one implementation per module (or the module has to "cheat", and pretend it is implementing on behalf of another module, one that might not even exist).
• The procedural code feels out of place compared to the rest of Drupal.

Alternatives:

• symfony events require a dedicated event class per event type instead of named parameters, which "creates additional boilerplate when defining events and additional levels of indirection when subscribing to events." (quote from #2237831). See #2551893: Add events for matching entity hooks
• tagged services and services collectors typically require a dedicated interface per "event type", and subscribers (= tagged services) to implement that interface.

None of these "alternatives" is a good candidate to fully and generically convert the existing hook system. All past attempts to do so (that I am aware of) only focused on very specific hooks, or families of hooks.

Proposed resolution

The Hux module allows to mark methods on services classes as hook implementation, using php attributes.

Something similar should be added in Drupal core, so that existing hook implementations can be converted to OOP code.

This seems to be the current consensus in #2237831: Allow module services to specify hooks.

class MyService {
  #[Hook('node_insert'), Hook('node_update')]
  public function nodeWrite(NodeInterface $node): void {..}
  #[Alter('form_node_edit_form')]
  public function nodeFormAlter(array $form, FormStateInterface $form_state): void {..}
}

Goals / requirements

Backwards support:

• The first iteration of this should be fully compatible with existing procedural hook implementations and also on the calling code side.
• There will be a mix of procedural and non-procedural implementations.
• The old hook_module_implements_alter() will still work on the list of procedural implementations, but a new hook (or event?) could be added to reorder or alter the collection that includes OOP implementations.
• The behavior and return value of any call to $module_handler->invoke() or $module_handler->invokeAll() etc...
  • ...must remain unchanged, if no new implementations were added.
  • ...must remain unchanged, if existing implementations are merely converted to the new system.
  • ...must only gradually change, if new implementations are added using the new system.
• Modules can start implementing existing hooks using the new system, without any change in the module that publishes or invokes the hook.

Basic new features:

• Methods on service classes can subscribe to hooks using attributes like #[Hook('node_update')].
• One method can implement more than one hook.
• Multiple methods in the same module can implement the same hook, resulting in multiple implementations per module.
  This introduces some challenges with return value of single $module_handler->invoke(..), see below.
• There must be a mechanism to order different implementations. E.g. in hux there is a system of weights / priorities, but in core we might do something different.
• There must be a mechanism to replace or remove existing implementations.
• For the two requirements above, it might be necessary to have unique machine names for individual implementations.

Optional or advanced features:

• There can be a discovery mechanism to register classes with hooks as services. E.g. in hux, this happens if these classes are in a Drupal\\$modulename\\Hooks namespace.
• Modules can add additional attribute classes, to let the method implement one or more hooks. E.g. #[HookEntityOp(['node', 'taxonomy_term'], ['update', 'insert'])] would implement 4 different hooks.
• Modules can add other callbacks as hook implementations, that don't rely on php attributes, and that can be added dynamically.
• We might add additional methods to ModuleHandler, with more control of the results aggregation for single ->invoke(). See "Challenges" below.
• We might add hooks (or anoother mechanism) to control the default results aggregation per hook name.

Challenges

• Return value of single $module_handler->invoke():
  • Currently, it returns the return value of the one single implementation. The behavior for this case must not change!
  • With multiple implementations that return arrays, e.g. for hook_schema(), we would expect the results to be merged. Any null values would be skipped, if the "collected data" is already an array.
  • For more than one non-array non-null values, or a mix of array and non-array values, an exception could be thrown, because these cannot be merged, unless an aggregation method is specified somewhere.
• Design a system to define order of implementations, and to remove or replace implementations. Options:
  • Before/after rules, as proposed for events in #2352351: Add before/after ordering to events
  • Numeric weights/priorities, as currently in hux.
  • A hook or similar to alter the list of implementations, similar to hook_module_implements_alter(), but with support for callbacks.
  • Extending hook_module_implements_alter() in a BC-friendly way. This could be tricky.

Underlying architecture

The module handler ->invoke(), ->invokeAll() etc should operate with a list of callbacks, that can come from different sources.
The methods with attributes will be one such source, but it should be flexible enough to support other sources.

Proposed roadmap / target versions

• Study and play with the hux module as a proof of concept.
• Build the new system in latest version of Drupal 10 (10.2.x). Do not change the existing implementations and calling code, yet.
  This allows contrib to start using the new system, while minimizing disruption from upgrading to the new core version.
  Any possible BC conflict will only apply if there is a module that uses the new system.
• Start converting existing implementations in a future version - 10.? or 11 - depends how disruptive this turns out to be.
• Add additional changes that are not backwards compatible, consider to deprecate procedural hooks, in Drupal 11.

Remaining tasks

User interface changes

API changes

Methods in service classes can be marked as hook implementations using attributes.
Details are provided above.

Data model changes

Caches for the new kinds of implementations and discovery data.

Release notes snippet

Problem/Motivation

Currently a process plugin can declare a row to be skipped by throwing a MigrateSkipRowException. Using exceptions as signals in this manner is not ideal. The process plugins have access to the $row. They should simply be able to set a flag on the row and return rather than trying to pass an exception up through the executable.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Background: We currently do most of our development against the "Most recently opened Development Branch", and when the first alpha of that minor is released, we open a new branch, which then logically changes what the "Most recently opened Development branch". Anything that's eligible to apply to either the currently supported minor or previous minor (security patches) is then cherry picked to those lower branches.

Problem: This means that our "logical HEAD" of core is a moving target that changes every six months, and perhaps more frequently when we add in Major version branch openings as well.

This causes a couple of problems:

1. Issues are assigned to a specific branch, like "9.3.x" that then have to be re-assigned to the new logical HEAD. In the vast majority of cases these issues aren't actually targeting the specific branch, they are trying to chase the logical HEAD, and when that HEAD changes labels (i.e. from 9.3.x->9.4.x) we have to go through a process to manipulate all of the issue metadata to move them.
2. Now that we have merge requests, those MRs also need to be migrated to be filed against the latest logical HEAD. We currently do not have a programmatic way to accomplish this, and the permissions on gitlab only allow the opener of the MR to do it, so even manual community issue grooming is onerous, and sometimes demands a new MR be opened to move branches.
3. A new user to the project doesn't have an obvious signpost where development happens. They have to look at all the open branches, and deduce that the highest numbered one is where all the momentum is happening. -> it is more common in projects for main is the place where work happens.

Proposed resolution

Ideally we would switch our logical HEAD to main asap, however Drupal.org does not have support for non-numeric branches out of the box.

Instead, we can implement an interim step on Drupal.org which should work with minimum or zero d.o changes and only minor core changes:

• Branch 11.x instead of 10.2.x now (i.e. 10.1.0-alpha/beta period).
• 11.x will follow 10.x minor release commit rules for the time being, no 11.x-specific patches yet and no 10.2.x branch.
• When we are ready to tag 10.2.0-alpha1, we would then branch 10.2.x and tag all 10.2 releases from there. The 11.x branch then continues as HEAD.
• When we need to diverge 11.x and 10.x, we would branch 10.LAST.x. 11.x would then start to get 11.x-specific commits
• When we're ready to tag 11.0.0-alpha1 we would branch 11.0.x and tag all releases from that branch.
• Continue with 11.x minor branches branched off 11.x when they reach alpha
• Hopefully, by the time we're working on 12.x, we'll be able to branch 'main' and work from that indefinitely.

Advantages:
One bulk issue update from 10.1.x to 11.x, and eventually a bulk issue update to 'main' in two or so years, instead of every six months. Same with branch retargeting.

DIsadvantages:
It is weird and non-semantic to use 11.x as the target for 10.x commits and release branches, however this will only be the case for a few months, then it will fold into sync with the 11.x release cycle anyway.

Original Proposal: Change our logical HEAD to main. All of our current existing policies would still apply, with one exception: instead of opening "the next branch for development" when we release an alpha, we instead open the release branch for that release at the time the alpha is released. (Do nothing with d7 and leave it as it is)

Example

(Now out of date in terms of current version, but still conveys the idea)

The current regime:
All of our commits happen to 9.3.x and:

The proposed strategy:
(rename current 9.3.x to main)
All of our commits happen against the main branch

So essentially: we develop in main untilwe open a release branch, at the same time that we make that branch's first release.

Question: The one part of this change that I'm unfamiliar with is what we do around major version branch releases:

If we are opening 9.4.x and 10.0.x at different times, then with this change in place we would open the 9.4.x branch when we are ready to start committing '10.0.x only' changes to main

Implementation considerations:

• Add main as a 'dev' release?
• Do we need both a 'main' and a 'next'?
• Allow main to exist in the version selector for issues
• Look at places where 'branch' might be standing in for a version.
• disable force pushes to main - at least for core.

Remaining tasks

• Finalize decision
• Identify all places where there are hard coded assumptions about 'branch' and 'version'
• Choose an appropriate transition window in an upcoming version cycle
• Documentation changes, including wiki pages and policy

User interface changes

Release notes snippet

With using the `domain access` module the `node access` functionality is used for checking permissions.
There is no problem with displaying a separate node. But any view does not display nodes in a language other than default.

Investigation showed that the `alterQuery` method in the `\core\modules\node\src\NodeGrantDatabaseStorage.php` method is responsible for the node's accessibility.

In order for the method to work correctly, the required language must be in the query metadata. For example, the "interface language" from the views filter. However, it is not in the query metadata.

I’m not completely sure that this task applies to the node or view module. Or maybe even domain access module. But once the code expects this parameter in the metadata, I created a patch that adds the language from the view filter.

Problem/Motivation

In #2767857: Add destination to edit, delete, enable, disable links in entity list builders we added destination query parameters to config entity lists and operations in Views. This unearthed the fact that some of our forms are not destination query compatible - we broke the image style user interface unexpectedly. See #2940165: [regression] Cannot add effects to image style via the UI.

The problem is that the destination param is set to win regardless of what a user does in the form. This means that any Drupal form can be redirected to somewhere using it.

As discussed in #2950759: Revert 2767857, right now, it is necessary to alter the global request object to disable a destination query arg based redirect override. That's complicated to understand and we shouldn't be doing something like that.

Older related issues are:
#579366: How many ways are there to redirect after form submission?
#1627654: drupal_redirect_form() should state that it is overridden by a destination in the request
#2325463: Destination URL breaks preview

Proposed resolution

We need a way to set a higher priority redirect on a form. So the developer can say actually regardless of the destination parameter go here because obeying the redirect makes no sense. The fix however shouldn't be tied to the forms system so the patch at the moment adds a new IgnoreDestinationRedirectReponse and the RedirectResponseSubscriber checks and doesn't apply the ?destination override if it is.

However since 90% of the redirects we are interested are from Forms the patch also adds helpers to FormState to make redirects behave like this.
FormStateInterface::getIgnoreDestination()
FormStateInterface::ignoreDestination($status)

Remaining tasks

Add more tests. One is currently provided by core/modules/image/src/Tests/ImageAdminStylesTest.php which proves this fixes #2940165: [regression] Cannot add effects to image style via the UI whilst bringing back the nice consistent UI behaviour of #2767857: Add destination to edit, delete, enable, disable links in entity list builders for Image Styles.

User interface changes

API changes

Data model changes

Problem/Motivation

Views contextual filters break when values contain forward slashes or when they contain hyphens and the "Transform spaces to dashes in URL" option is enabled. If a view is configured to display a summary if the filter value is not in the URL in one of these two cases, Views will print links that lead to broken pages. See #29 for a detailed description of the symptoms.

Proposed resolution

The solution may be to specially encode hyphens and forward slashes. (There are some workarounds detailed in #16 that may help folks who need a solution now.)

Remaining tasks

• Code the changes
• Write regression tests

User interface changes

Probably none.

API changes

None, per se. Encoding and decoding rules for contextual filters may change slightly.

Original report by @TravisCarden

A View with an argument set to display a summary if the argument is not present will create non-functioning links (or, more precisely, links to paths with arguments that don't work) if the terms (I've only tested with taxonomy arguments) contain any pound signs, plus signs, dashes, or backslashes (#+-/). The following special characters work just fine: !"$%&'()*,.:;<=>?@[\]^_`{|}~. I didn't test anything crazier than that. I realize this may be somewhat expected behavior, but I'm going to argue it's a bug because the broken links themselves are being generated by Views.

Problem/Motivation

The Entity Reference field has two display widgets: "Autocomplete" and "Autocomplete (Tags style)".
Both widgets allow users to add new taxonomy terms to a vocabulary as long as "Create referenced entities if they don't already exist" is enabled on the edit tab of the field. Terms cannot be added if that tick box is not ticked.

Proposed resolution

Since there doesn't seem to be any difference in the functionality of the two widgets "Autocompelete (Tags style)" could be removed.

Remaining tasks

User interface changes

API changes

ok, so really excited at installing drupal7, saw some new installer things which made me go "oooh". then after installing, i see the "congrats, now onto your new site" ... and excited, i'm greeted with lots of...text that just blends together and looks rather dull.

i think it would be a huge boon for drupal if each of the four steps could be described with an image (split across four cols) and a brief description underneath. i think it'd be a great visual clue, memorable, a nice welcome to the new drupal site.

i'm not a designer, but i think the steps lend themselves well to visuals anyway.

what do you think?

if you think it sucks, then another criticism would be i think there's too many hyperlinks that look disjointed, so if you're all against the above idea, then i'd like to propose the text as being something like:

Administration (link to somewhere)
Drupal makes life easy for site administrators. The administration section is where you tailor your site to your exact needs, manage your content and users.

Modules (link to admin/build/modules)
Drupal is extendable. Modules allow you to expand Drupal to add extra features for your site, such as (basic examples)

Themes (link to admin/build/themes)
Make your Drupal site look the way you want by using themes. Drupal has a few default themes, and you can find many more at drupal.org/project/themes/. If you can't find one you like, then feel free to design your own.

Content (link to create section?)
Drupal makes it easy to add content for your site. Catagorise it using taxonomy, and manage it in the administration section.

---

the text is still trying to 'sell' drupal - with it being so easy to install now with sqlite, people could just as easy uninstall it, and has a consistent title with link and description style.

Attached patch fixes up some of the excessive caching we added during D7. In our zeal to avoid mysql load, we cache even fast queries because it is faster and more reliable to fetch from memcache, mongo, etc.

The patch creates cache_get_memory() and cache_set_memory() which no-op unless an in-memory cache backend is in use. Core won't set its DB backend to in-memory but memcache and others will. Setting this flag is all they have to do to gain these advantages.

You can see the node.module hunk of the patch that only a tiny change is needed at call time. This hunk refines the persistent caching added at #898360: Cache node types such that it only happens for memcache and similar backends. Upon positive feedback, I will add similar changes in other parts of core.

I think this is a good compromise. Open to other ideas.

Problem/Motivation

I have an image field with a minimal resolution bigger than 600x600. When i use Devel Generate to create default content. The generated images resolution are smaller than the defined minimals in the field.

Steps to reproduce

1. Create a content type with a minimal resolution of 800x800 ( any resolution bigger than 600x600 works to reproduce the bug).
2. Run devel generate to create content of that content type.

Proposed resolution

The generateSampleValue method should check if the minimal resolution is bigger than 600x600, and redefine the max_resolution value accordingly.

Remaining tasks

Add tests, see #12

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Please review the provided patch.

Problem/Motivation

As mentioned in the parent issue #3238306: [META] Where possible, refactor existing jQuery uses to vanillaJS to reduce jQuery footprint, we are working towards reducing our jQuery footprint. One of the ways to accomplish this is to reduce the number of jQuery features used in Drupal core. We have added eslint rules that identify specific features and fail tests when those features are in use.

There are (or will be) individual issues for each jQuery-use eslint rule. This one is specific to jquery/no-is, which targets the jQuery is function.

Steps to reproduce

Proposed resolution

Remaining tasks

• In core/.eslintrc.jquery.json Change "jquery/no-is": 0, to "jquery/no-is": 2, to enable eslint checks for uses of jQuery css(). With this change, you'll be able to see uses of the undesirable jQuery feature by running yarn lint:core-js-passing from the core directory
• Add the following lines to core/scripts/dev/commit-code-check.sh so the DrupalCI testing script can catch this jQuery usage on all files, not just those which have changed
  

  # @todo Remove the next chunk of lines before committing. This script only lints
  #  JavaScript files that have changed, so we add this to check all files for
  #  jQuery-specific lint errors.
  cd "$TOP_LEVEL/core"
  node ./node_modules/eslint/bin/eslint.js --quiet --config=.eslintrc.passing.json .
  
  CORRECTJQS=$?
  if [ "$CORRECTJQS" -ne "0" ]; then
    # No need to write any output the node command will do this for us.
    printf "${red}FAILURE ${reset}: unsupported jQuery usage. See errors above."
    STATUS=1
    FINAL_STATUS=1
  fi
  cd $TOP_LEVEL
  # @todo end lines to remove

  Add the block about 10 lines before the end of the file, just before if [[ "$FINAL_STATUS" == "1" ]] && [[ "$DRUPALCI" == "1" ]]; then, then remove it once all the jQuery uses have been refactored.

• If it's determined to be feasible, refactor those uses of jQuery is() to use Vanilla (native) JavaScript instead.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

I configured my multi-value entity reference field's form display as 'Autocomplete (Tags style)' yet it renders as a regular Autocomplete widget and only lets me select one value. If I try typing in part of another reference's title, it does not autocomplete that one. It also is not rendering as a tag, as I thought it might (like it did in D7). I am unsure what the expected behavior is, but this does not seem right.

See attached screenshot. I am running into this on both D9 and D10. I tested with Claro and Olivera as my admin theme on D10, and with Claro and Bartik as my admin theme on D9. The issue was the same in all cases.

There are no JavaScript errors, nor any errors in the Drupal watchdog / logs.

Steps to reproduce

Create an entity reference field and configure it to display with 'Autocomplete (Tags style)'.

Proposed resolution

No idea! Just flagging it.

Remaining tasks

Fix it :)

User interface changes

Make the 'Autocomplete (Tags style)' work with multi-value fields and, assuming it is intended to render with some tag-like styling, render it with tag-like styling.

API changes

Unknown.

Data model changes

Unknown.

Release notes snippet

n/a

Problem/Motivation

There is a great deal of info about what actually went wrong when you performed a migration, but it is all kept in tables called migrate_message_% with no mechanism in core (UI, command-line prompt, etc.) to extract info. Ideally, there would be a searchable/filterable view of this information.

Proposed resolution

Add a new page at admin/reports/upgrade-messages with a summary, and child pages that display the messages in any migrate_message_% table. Add the ability to filter on the migration and the severity.

The new pages call the fields() method of the related source plugin. Some of these need to be updated to catch exceptions when the source database has not been configured:

• MenuLink.php (There are also a lot of uses of the global t() in fields().)
• Menu.php
• d7/User.php
• d6/User.php (in baseFields())
• d6/ProfileFieldValues.php

Work-around: There is a drush command to view the messages, drush mmsg migration-name available from migrate_tools and migrate_run.

Remaining tasks

• Postponed on #3312733: SQL migrations cannot be instantiated if database is not available and Node, Migrate Drupal modules are enabled.
• Use a thin controller, see #42.6. (Follow-up issue?)
• Review
• Agree on wording for the explanation of 'Not available' in some columns.
• Agree on names that align with the changes in #2713327: Provide a way to remove migration tables (ID map etc.).
• Potential new issue for the changes here in Menu.php (done as part of this issue)

User interface changes

New pages for displaying messages from the migrate_message tables.

• Migrate with Migrate Message
• Migrate Drupal UI with Migrate Messages
• Migrate with Empty Migrate Message Tables
• Migrate Drupal UI with Empty Migrate Message Tables
• Migrate with No message tables
• Migrate Drupal UI with No message tables
• D7_menu

Some screenshots are missing the period at the end of this sentence, "This page allows you to view these messages.". It has been fixed in the patch in #116, I just didn't make new screenshots for that.

API changes

None

Data model changes

None

Release notes snippet

TBD

Originally (like a year ago), "field settings" were those things which affected schema and could not be changed except by a mythical "field conversion" system and "instance settings" were the lightweight things that could be changed at any time.

Later, we realized that some things should be field settings so they are inherited by all field instances even though they do not actually affect the schema. "Allowed values" for a list field is the standard example.

While discussing taxonomy as a field at the DCDC code sprint, we realized that even though changing some field settings would not affect the schema, they would still constitute an expensive operation. For example, suppose a list field changes its "allowed values" by removing some of the allowed keys. The site may already have data items for that field in the database that use the removed keys and are thus no longer valid (they would not pass field validation). In the taxonomy case, if a taxonomy field indicates which vocabs are allowed, and that changes, existing data items may then contain terms from a vocab that is no longer valid for that field.

This leads to a situation in which we need:

1. Field settings that cannot be changed except by a field conversion process. These include schema settings and anything that affects what constitutes valid data for the field.

2. Field settings that can be changed. Given the "valid data" constraint, are there remaining known use cases for this?

3. Instance settings that can be changed, like "required" and "weight."

If the Field API is going to support 1 and 2, then it also needs to provide some way to differentiate between them so the UI knows what to display on a field edit form.

Problem/Motivation

If a page has a URL like /blog?tag=security&page=4, the canonical URL will be rendered as /blog?tag=security&page=4.

This will cause problems with SEO and crawlers as they depend on canonical links to be valid. It also makes it impossible to meet Google's recommendations on how to indicate paginated content properly. This is why this issue is initially marked Major.

To reproduce this:

- Create a SimplyTest.me project using the MetaTags module
- Add the metatags field to the basic page content type
- Create a basic page and use the Metatag advanced setting to set the canonical URL to /blog?tag=security&page=4
- Open in Chrome and view the page source (Note: Inspect will hide the & value).
- The canonical href will have be encoded.

Proposed resolution

The underlying problem is in the HtmlTag code. It creates the tag markup using the Attribute class's __toString method. This method escapes all attribute labels and values.

The fix here is to handle link tag href attributes and script tag src attributes as special cases in the HtmlTag code.

The HREF and SRC attributes should not be added to the Attributes class. Instead, their values should be validated with UrlHelper::isValid(). If they fail validation, then they should be fully escaped. These attributes should be added to the tag directly. All other attributes should go thru the Attribute class.

Remaining tasks

- Write the patch
- Write some tests

User interface changes

None

API changes

None

Data model changes

None

Problem/Motivation

A customer with admin privileges might freak out if they read about security updates, etc. This issue branched off of a similar issue: http://drupal.org/node/1177752#comment-5463890

In system.admin.inc line 14 which there should be permission handling for this message which appears to all users who can see an admin screen.

drupal_set_message(t('One or more problems were detected with your Drupal installation

Proposed resolution

Put access control on this line in system.admin.inc or move this to the update module perhaps which as I mentioned Bryanhirsch just put permissions on a similar thing in http://drupal.org/node/1177752#comment-5463890

Remaining tasks

code needs writing, it needs testing.

User interface changes

the warning text wont show if the user doesn't have permission to see these messages

API changes

no api changes

It's a well-known problem that you can't use the node:nid token in a node's automatic title (#176468: The token "[nid]" doesn't work.), and more generally, anything that you want to do with an entity that you might want to do to a brand new entity and which needs the ID, won't work.

So here's my idea. What if we 'pre-booked' the ID, by entering a mostly empty row in the entity's table before all the save hooks are fired?

Here's pseudocode to illustrate this:

function entity_save($entity) {
 // Pre-book a row.
 $new_row = drupal_write_record(entity table, array());
 
  $entity->id = $new_row->id;

  // Fire the rest of the normal save procedure and fire the usual hooks.
}

We'd presumably need a different way of knowing it's a new entity rather than an update as most hooks will use the presence / absence of the id key. But apart from that, could this work?

Problem/Motivation

Single directory components (SDC) is a new way to theme Drupal. Instead of scattering related files around your theme, they're contained to one directory. The primary issue for SDC is at #3313520: Single directory components in core.

As part of SDC's roadmap (see #3345922: Single Directory Components module roadmap: the path to beta and stable), we want to convert an Umami component to use SDC. For this task I'm choosing the c footer promo component, which includes markup and CSS.

Testing instructions

1. Make sure you have SDC module enabled, if enabling via drush si demo_umami it will be installed by the profile
2. Clear caches
3. Test footer promo - you should see HTML like the screenshot below showing that the cards are being rendered via a component