Packages were held back because of the older version of PHP should now be upgradable since we use PHP 7.2.
Upgrade all the packages we can.
Test all the things.
None.
None (hopefully).
None.
TBD.
Importing all configuration (even multiple time) do not clear change.
It seems to append when the configuration has empty item.
from @greg.1.anderson on #3091418: Update composer dependencies on 9.0.x.
When we are bumping the Composer dependencies for a major Drupal version release, perhaps we should also make a policy that we increase all of the version constraints for all components listed explicitly in core/composer.json to whatever minimum version they happen to resolve to in composer.lock at that time. Folks will already be adjusting their code to work with the new version of Drupal; it seems like the need for supporting anything older than what is in composer.lock would therefore be minimal. While this is not required, doing this reduces the number of versions of dependencies supported by Drupal, and reduces the number of valid versions of dependencies that are potential solutions from the Composer resolver. (This does not help the current default algorithm, which tries all permutations, but we already have some Composer plugins which optimize this, and such a reduction might help future versions of these do even better.)
This issue is split off from #3091418: Update composer dependencies on 9.0.x to address doctrine/* Composer requirements.
Per @catch in comment #40:
The Doctrine website is showing several of the versions updated to here as unsupported, with newer versions in development (but not released yet) and only older versions still supported (some still more recent than the versions we're on).
Went through a few.
I have no idea why they have essentially 'dead end' versions with releases from two months ago, it could possibly be their website not updated fully yet, but I think we need to investigate a bit more.
+++ b/composer.lock @@ -244,30 +244,30 @@ { "name": "doctrine/annotations", - "version": "v1.4.0", + "version": "v1.8.0", "source": {I don't think we can go to doctrine/annotations 1.8
1.8 is unsupported, 2.0 is upcoming, 1.7 is supported, according to
+++ b/composer.lock @@ -308,37 +308,42 @@ { "name": "doctrine/cache", - "version": "v1.6.2", + "version": "1.10.0",Similarly doctrine/cache 1.10 is unmaintained, only 1.8 is
+++ b/composer.lock @@ -372,44 +377,53 @@ { "name": "doctrine/collections", - "version": "v1.4.0", + "version": "1.6.4",This is OK.
+++ b/composer.lock @@ -438,44 +452,53 @@ "name": "doctrine/common", - "version": "v2.7.3", + "version": "v2.11.0", "source": {This is also OK.
+++ b/composer.lock @@ -507,35 +604,39 @@ { "name": "doctrine/inflector", - "version": "v1.2.0", + "version": "1.3.1",And this is OK too.
+++ b/composer.lock @@ -585,32 +686,34 @@ { "name": "doctrine/lexer", - "version": "1.0.2", + "version": "1.2.0", "source": {Can't update this one for the same reason
+++ b/composer.lock @@ -645,7 +748,165 @@ - "time": "2019-06-08T11:03:04+00:00" + "time": "2019-10-30T14:39:59+00:00" + }, + { + "name": "doctrine/persistence", + "version": "1.3.3", + "source": { + "type": "git", + "url": "https://github.com/doctrine/persistence.git", + "reference": "99b196bbd4715a94fa100fac664a351ffa46d6a5" + }, + "dist": {This one is OK. https://www.doctrine-project.org/projects/persistence.html
And again in comment #40:
OK I might have found part of the problem here, see this announcement:
https://www.doctrine-project.org/2018/07/12/common-2-9-and-dbal-2-8-and-...
If the left_field is a formula then the left_table should be null. Here's the corresponsing fragment from the JoinPluginBase:
if ($this->leftTable) {
$left_table = $view_query->getTableInfo($this->leftTable);
$left_field = "$left_table[alias].$this->leftField";
}
else {
// This can be used if left_field is a formula or something. It should be used only *very* rarely.
$left_field = $this->leftField;
$left_table = NULL;
}
(source)
However, the ::buildExtra method produces invalid sql in this case, e.g.
media__field_tags.langcode = .langcode
and that breaks the views query. It's added here:
if (isset($info['left_field'])) {
$placeholder_sql = "$left[alias].$info[left_field]";
}
(source)
Add the left table alias to the query only if the left table is set.
None.
None.
None.
None.
Fixed a bug with formula handling in the extra conditions of a views join that caused problems when using the workspaces module.
#3041924: [META] Convert hook_help() module overview text to topics for the basic_auth, hal, jsonapi, rdf, rest, and serialization modules.
NOTE: What is below is the generic instructions for converting hook_help to topics. We want to end up with task-based topics; in this case, there really aren't "tasks" per se for these modules. So let's just make one topic called something like "Enabling web services on your site" with a filename starting with "core." (so it is not in one module's namespace), and describe what web services are, and what each of these 5 web services modules does.
Take the information that is currently in the hook_help module overview section for the module(s), and make sure the information is in one or more Twig help topic files. Steps:
switch ($route_name) {
case 'help.page.contact':
And ends either at the end of the function, or where you find another case 'something': line.
core/modules/help_topics/help_topics. Note that to see existing topics, you will need to enable the experimental Help Topics module (available in the latest dev versions of Drupal 8.x).
core/modules/help_topics/help_topics. You will need to choose the appropriate module prefix for the file name -- the module that is required for the functionality. Alternatively, if the information spans several modules or if the information should be visible before the module is installed, you can use the "core" file name prefix. For instance, it might be useful to know that to get a certain functionality, you need to turn on a certain module (so that would be in the core prefix), but then the details of how to use it should only be visible once that module is turned on (so that would be in the module prefix). a) Make a patch (see Proposed Resolution section).
b) Review the patch:
admin/help/topic/rdf.overview within your site.admin/help/MODULENAME. Verify that all the tasks described in these overview pages are covered in the topics you reviewed.Help topics will be added to cover tasks currently covered in modules' hook_help() implementations.
None.
None.
None.
#3041924: [META] Convert hook_help() module overview text to topics for the search module(s).
Take the information that is currently in the hook_help module overview section for the module(s), and make sure the information is in one or more Twig help topic files. Steps:
switch ($route_name) {
case 'help.page.contact':
And ends either at the end of the function, or where you find another case 'something': line.
core/modules/help_topics/help_topics. Note that to see existing topics, you will need to enable the experimental Help Topics module (available in the latest dev versions of Drupal 8.x).
core/modules/help_topics/help_topics. You will need to choose the appropriate module prefix for the file name -- the module that is required for the functionality. Alternatively, if the information spans several modules or if the information should be visible before the module is installed, you can use the "core" file name prefix. For instance, it might be useful to know that to get a certain functionality, you need to turn on a certain module (so that would be in the core prefix), but then the details of how to use it should only be visible once that module is turned on (so that would be in the module prefix). a) Make a patch (see Proposed Resolution section).
b) Review the patch:
admin/help/topic/action.configuring within your site.admin/help/MODULENAME. Verify that all the tasks described in these overview pages are covered in the topics you reviewed.Help topics will be added to cover tasks currently covered in modules' hook_help() implementations.
None.
None.
None.
Hi..
My website have multilanguages, and my default language is Indonesia and the second language is English. I got this error : "Parse error: syntax error, unexpected '?' in ..../MailManager.php on line 316" after updated to drupal 8.8.0.
Anyone have faced this ? please advise
Thank you
Updated: Comment #74
New users registering accounts on a Drupal site can lose the welcome email to their spam filtering software.
New users can be created/imported into a Drupal system in bulk, and then it would be useful to be able to send a welcome email manually afterwards - #8.
Add the ability for users with the requisite permissions to re-send the welcome email to a user by visiting user/edit/XXX or using batch action in /admin/people.
Only users who can register accounts can re-send the welcome email - #71
RTBC working patch.
A new button "Re-send welcome message" appears on the user edit page for users with the correct permissions to use it.
Screenshots available at #44 and #73
None.
It would be nice if the admin could force a resend of the welcome message from the user edit page.
One case where this would be useful:
Many people are using spam-filtering software these days which make use of white lists, and the Drupal website sending address is not yet known to the user requesting an account.
It is becoming increasingly clear, both throughout core and in contrib, that Twig templates need the ability to associate contextual metadata with them.
Typically, in the past, this has been done using standalone/custom YAML files (like with layouts: *.layouts.yml). Previously, in the case of help_topics this metadata was being embedded using HTML <meta> tags inside the templates themselves (this has since been switched to using a stand-alone front matter implementation in anticipation of this issue).
While this technically works and is filtered out during XSS processing, it creates yet another coding paradigm FE developers have to be aware of. The primary reason this was done was to keep the relevant information with the template it is associated with.
From @alexpott in #2920309-321: Add experimental module for Help Topics:
Having to define a help topic in both a yaml file and then create a separate twig template was bothering me. The reason we went for annotations was to keep the discovery along with the code. I think the same rule appears here.
Suffice it to say: we need a standardized way of associating inline metadata with templates.
Being able to associate metadata with a template can also lend to newer innovations for problems we've had in the past.
There are many ideas of how we can help alleviate BC issues with Twig templates, almost all would likely require the ability to provide some sort of metadata with them; if only for some sort of identification, filtering, or sorting purposes.
Allow the use of Front Matter YAML blocks at the top of template files.
Front Matter was made popular by Jekyll and has since become sort of the "industry standard" way of associating metadata with any sort of document.
Note that the framework manager review of this approach was done in comment #160. The framework managers decided that this approach (putting the front matter in YAML format at the top of files, and not enclosing it in comments or other delimeters) was the best approach to use. There was a lot of discussion of the pros and cons of this and other approaches... There was an attempt at a summary in comment #134, and then a bunch of additional discussion, then another summary in comment #157.
None
None
None
A new component has been created to parse front matter from sources. See the change record for more information.
During development, example.settings.local.php is frequently duplicated and used as is, or with minor modifications. One of the lines that's included by default is enabling local development services. Editing this file to turn on twig debug or disable caching is a common step in the development process.
However, because this file is part of Drupal core, it is overwritten back to its default value any time core is updated via composer.
I would propose renaming development.services.yml to [example/default].development.services.yml while leaving the rest of the related core files as is. This would encourage developers to create a new file not included in core that is therefore not overwritten during the update process.
I found a session error in Drupal version >= 7.68 with PHP 5.2.
Detailed steps:
1) The user tries to recover his password and receives the email for recovery.
2) When clicking, the user logs into the site and automatically falls to the screen to change password.
3) When filling in the new password and saving the following error is displayed: Fatal error: session_start () [ function.session-start ]: Failed to initialize storage module : user (path: /var/lib/php/session) in /drupal/drupal-7.68/includes/session.inc on line 287
We found that the error occurs with php version 5.2 and happens in this function, specifically in the 3 lines below (Between 'Begin error code' and 'End error code'):
/**
* Regenerates an existing session.
*/
function _drupal_session_regenerate_existing() {
global $user;
// Preserve existing settings for the saving of sessions.
$original_save_session_status = drupal_save_session();
// Begin error code
// Turn off saving of sessions.
drupal_save_session(FALSE);
session_write_close();
drupal_session_started(FALSE);
// End error code
// Preserve the user object, as starting a new session will reset it.
$original_user = $user;
session_id(drupal_random_key());
drupal_session_start();
$user = $original_user;
// Restore the original settings for the saving of sessions.
drupal_save_session($original_save_session_status);
}
In this post, https://www.drupal.org/project/drupal/issues/3009351, that this function was included in drupal version 7.68 and that these three lines refer to a specific problem of PHP 7.3, as commented in the code. https: //www.drupal.org/files/issues/2018-12-30/3009351-23.patch
Currently there is a overflow/scrollbar for the entire page, if the page is viewed on a mobile device and the page contains a table.
We introduce the "overflow-x: scroll;" CSS declaration to remove the overflow. So only the table will be horizontally scrollable and the other content will suite the viewport.
Opening the Drupal 9 branch allows a few things to happen.
In order for the Drupal 9 branch to be useful, we need to be able to do the below things soon after the branch is opened.
The 9.0.x branch opened alongside 8.9.x according to the normal release schedule.
Once these issues are resolved, a Drupal 9 branch becomes useful, because it allows for contrib testing of the upgrade path and updated dependencies. The release notes for the alphas will specify that deprecated code has not yet been removed entirely and that any use of deprecated code by contrib/sites will be incompatible by beta1.
Requirements for beta1 are at #3079680: [META] Requirements for tagging Drupal 9.0.0-beta1.
The use of HTML5 "required" attribute in D8 has resulted in an accessibility regression. Basic client-side validation now occurs *before* hitting the server and running FAPI validation functions, so the browser jumps in and provides an error as you attempt to submit the form.
In Drupal 7, the FAPI error messages include a) an icon + alt tag to indicate their relative importance (e.g. warning/notice), b) an error message which included the name of the field for reference, c) a red outline on the field.
But in D8, those enhanced error messages are never displayed, in favor of the default browser response to a required field, which in Chrome's case is "Please fill out this field," without any mention of which field is referred to.
The accessibility team's goal for form validation is #1493324: Inline form errors for accessibility and UX. HTML5 best practices are:
Implementing Javascript validation before the HTML5 validation would restore accessibility for most users. A proposed patch changing the error message to "SomeFormField is required" would improve accessibility for those without Javascript.
#1696648: [META] Untie content entity validation from form validation
#742344: Allow forms to set custom validation error messages on required fields
#1845546: Implement validation for the TypedData API
I was very surprised to see that in D8 that we've lost some accessibility in the current release as far as how error messages are presented.
They were much better in D7. In D8 they just say "Please fill out this field.", where in D7 there was a red box describing the problem at the top of the page. The error also had an image and text which identified what exactly the problem was.
Ultimately we need this in core #742344: Allow forms to set custom validation error messages on required fields
But the defaults for D8 should be at least as good as they were in D7.
The ImageStyle class is a config entity that besides doing the config entity, also has methods that do process images into derivatives.
This is probably the result of the migration of the image system from D7.
As things stand, though, this is causing issues -
Some issues were filed in that respect, to list a few:
#2359443: Allow creating image derivatives from an Image object
#1358896: Flexible scheme and URI for image derivatives
#2940016: Make possible to respond to image derivative creation
#1826362: ImageEffects of the same image style should be able to pass variables between them
In #2359443-26: Allow creating image derivatives from an Image object, before stalling, we started discussing decoupling the config entity from the image derivative processing code.
This is implementing that:
Why a plugin?
So that the default implementation can be overridden e.g. to change the derivative URI calculation logic or to post-process an image derivative - only re-implementing the plugin methods that are necessary without touching the config entity code. But also, plugin allows to have parallel 'derivative processing engines' if someone wants that. For instance, Textimage contrib module has its own formatter and API that could leverage this plugin concept.
Review
None
Several methods deprecatedin ImageStyle, new plugin manager and a default plugin implemented.
None
Currently the oEmbed resource fetching in core requires that a specific set of data be returned as a Resource type, discarding data from the provider's return. There are two problems with this:
Add a method that supports returning the provider response.
Guzzle 7 went into beta this week. https://github.com/guzzle/guzzle/releases/tag/7.0.0-beta.1
We should test this beta with Drupal 9 and determine if we are compatible with it in case Guzzle 7.0.0 is released before Drupal 9.
core/composer.json requirement to the Guzzle 7 beta.N/A
N/A
N/A
Needed. TBD.
jquery.cookie is no longer a maintained library. A replacement should be found.
> git grep core/jquery.cookie core\core.libraries.yml | wc -l
3
> git grep -l cookie -- "*.js"
core/assets/vendor/jquery-joyride/jquery.joyride-2.1.min.js
core/assets/vendor/jquery.cookie/jquery.cookie.min.js
This is used in jquery.joyride and the only real usage I have found. Also, jquery.joyride is not hard dependency on cookies.
https://github.com/zurb/joyride/blob/v2.1.0/jquery.joyride-2.1.js#L32
Replace jquery.cookie with js-cookie library adding a backwards-compatibility layer. We can model the BC layer off of js-cookie v1.5.1 as well as the js-cookie v2.0.0 release notes (#26).
This approach was originally reviewed by droplet and confirmed by _nod in 2017. There is now a major version 3 in js-cookie that has a beta release. Should we continue to implement js-cookie 2, wait until 3, or find a different dependency to use?
Yes, with backwards-compatibility layer.
TBD
Because of #2807145: [policy, no patch] Allow contrib projects to specify multiple major core branches, Drupal 9 may need to retrieve modules that start with 8.x-. The update module is not currently aware that modules starting with 8.x can be compatible with Drupal 9. Also once as part of #3009338: [META] Support semantic versioning for extensions (modules, themes, etc) in Drupal core Drupal also need to retrieve modules that have semantic versioning releases and don't start with 8.x
Drupal.org now offers a new update xml feed /current that returns both 8.x- modules but also all the new semantic version modules that will be available.
We can't simply switch the /current feed because it does not have the same metadata for projects and releases.
\Drupal::CORE_COMPATIBILITY(8.x) as the final path segment. This should be replaced with 'current'. For example, a request that previously requested https://updates.drupal.org/release-history/paragraphs/8.x will now request https://updates.drupal.org/release-history/paragraphs/current/current has a somewhat different structure than what was returned by requests to /8.x, The update module and its tests will need refactoring to reflect those changes.
version_major, version_minor, version_patch, version_extrarecommended_major (which differed depending on the API requested) has been removed. This was only used to determine which major version should be used for available updates if the currently installed version is not supported. Instead the next major version that is supported, as determined by supported_branches. Since currently contrib modules don't have branches that have minor version the supported branches should be the same.
For core which does have minor branches this will not distinguish between minor core branches. This the same functionality that the update module currently provides for core since the current XML only sends recommended_major not branches.
supported_majors replaced with supported_branches, which includes core compatibility for non-semver version numbers.
In addition to determining the major version should be used as the target major for updates, all updates that are in unsupported branches will not be shown.
Follow-ups
#3100115: The update module should recommend updates based on supported_branches not majors
#3100386: Create contrib update module test cases that use semantic versioning