The scaffolding documentation link in README.txt refers to version Drupal 8.
see
https://git.drupalcode.org/project/drupal/tree/8.8.x/composer/Plugin/Sca...
Proposed resolution
see
https://git.drupalcode.org/project/drupal/tree/9.1.x/composer/Plugin/Sca...
Discovered in #2466197: Staging directory should not have to be writeable.
\Drupal\Core\Config\FileStorageFactory::getSync() just throws a \Exception when the config directory type does not exist - that's way too generic.
Create a more specific exception.
None
A new exception - but any code catching the existing exception will work because the new exception will extend from \Exception
user_password generates a random alphanumeric password.
The many contrib modules using it would be able to use this more easily if it were in it's own component.
Drupal does not rely on built-in PHP methods for generating the session id currently, but uses a random 32 byte value.
(see this commit; also note that the comment about "less random sessions" is wrong now).
NativeSessionStorage::regenerate completely and re-implement the mechanism in custom code (see #801278: Authenticated users getting "less random" session IDs).PHP 5.4 ships with improvements regarding session ID generation:
/dev/urandom or /dev/arandom if it is available (session.c (5.4) vs session.c (5.3)). On Windows, the Random API is used./dev/urandom or /dev/arandom present on compile time session.entropy_length defaults to 32. On Windows, this seemingly has to be configured manually.According to the OWASP PHP Security Cheat Sheet:
PHP's default session facilities are considered safe, the generated PHPSessionID is random enough, but the storage is not necessarily safe.
→ Remove our custom code for generating session IDs and rely on the native PHP functionality instead.
ProxyBuilder only has limited supported for built-in typehints like array and callable. It should support string, int etc... Also PHP 8 has deprecated \ReflectionParamter::getClass().
Fix it and add tests.
#3156542: \ReflectionParamter::getClass() is deprecated in PHP 8.0 handles other \ReflectionParamter::getClass() calls.
None
None
None
ProxyBuilder now supports scalar typehints like string
The node module provides a "syndicate" block, which contains a link to rss.xml.
The link text is an unfinished sentence: "Subscribe to".
The link is generated in SyndicateBlock.php using '#theme' => 'feed_icon'.
The corresponding feed-icon.html.twig template expects a top-level variable called title like so:
{{ 'Subscribe to @title'|t({'@title': title}) }}.
However no title variable has been passed in to the theme template by SyndicateBlock.php, so the link is an unfinished sentence. It's not clear what was originally intended for this to say. We could look back to how things worked in D7, but at this stage that might not be relevant any more.
Pass in a title in to the feed_icon template, so the link text makes sense.
I suggest we use the site name for this.
SyndicateBlock.phpWhen uploading multiple files in a file managed field and one or more files exceed the upload limit, the file name(s) are not shown.
The problem is the use of SplFileInfo->getFilename() for the error messages, which is empty. SplFileInfo->getClientOriginalName() should be used, like it is later for the file entity values array.
None.
The error message will change fromThe file could not be saved because it exceeds 2 MB, the maximum allowed size for uploads.
toThe file BILL FAY - BE NOT SO FEARFUL.mp3 could not be saved because it exceeds 2 MB, the maximum allowed size for uploads.
None.
None.
To run on PHP 8, we need to bump, among other things, the version of symfony. See https://github.com/symfony/symfony/issues/36872#issuecomment-653233968
Also we should update our dependencies prior to 9.1.0.
Run composer update
N/a
N/a
N/a
Dependencies are updated to latest version. See ...generate lock diff at time of 9.1.0.
In #3032686: Remove references to unused packages in Drupal 9's vendor hardening we added a test to ensure that packages that had been removed from composer.lock were also removed from our vendor hardening code.
We can go a step further and ensure that all packages listed in composer.lock are also listed in the vendor hardening code, even if there is nothing to harden; this ensures we have at least considered hardening for any new dependency.
Make the test in ComposerIntegrationTest::testVendorCleanup() stricter.
Decide if this is a good idea.
JSON:API has a nice feature in that it flattens a Drupal field value so we don't have pesky value sub-properties on things like string, boolean, email, etc fields. This is great, except when you want your field type to have a forced sub-property.
In the Commerce API module being developed we have a billing_information field that has at least an address property and may have more, such as a tax number or phone number.
Currently, the billing_information field just displays all of the address item values as root properties, causing a broken schema.
The relevant code is: https://git.drupalcode.org/project/drupal/blob/8.8.x/core/modules/jsonap...
$field_properties = TypedDataInternalPropertiesHelper::getNonInternalProperties($field_item);
// Flatten if there is only a single property to normalize.
$values = static::rasterizeValueRecursive(count($field_properties) == 1 ? reset($values) : $values);
getNonInternalProperties will return properties that are not computed or marked internal.
I had to make this workaround for myself:
/**
* {@inheritdoc}
*/
public function normalize($object, $format = NULL, array $context = []) {
assert($object instanceof Address);
// Work around for JSON:API's normalization of FieldItems. If there is only
// one root property in the field item, it will flatten the values. We do
// not want that for the OrderProfile field, as `address` should be present.
// This only happens if there is one field on the profile.
// @see \Drupal\jsonapi\Normalizer\FieldItemNormalizer::normalize
// @todo open issue FieldItemNormalizer::normalize should ignore if mainPropertyName is NULL.
$parent = $object->getParent();
if ($parent instanceof OrderProfile) {
$field_properties = TypedDataInternalPropertiesHelper::getNonInternalProperties($parent);
if (count($field_properties) === 1) {
// This ensures the value is always under an `address` property.
return ['address' => array_filter($object->getValue())];
}
}
return array_filter($object->getValue());
}
If there is one property returned by TypedDataInternalPropertiesHelper::getNonInternalProperties, check if it matches the main property value. In most cases it will, or getMainPropertyName wil be NULL. If it doesn't match, then do not flatten the field values. Often times getMainPropertyName returns NULL If the field type has multiple properties for its value and there cannot be a single property used (ie: price field, you need the number and currency.)
None.
JSON:API will no longer flatten field types which return NULL or a main property name which does not match the single property returned.
None.
Currently we are redirecting to <front> after a user submits the contact form. It seems like this was introduced in 744309f9 which is #2125253: Convert $form_state['redirect'] to $form_state['redirect_route'].
Let's remove the redirect to <front>so your visitors are not leaving the contact form. There is another issue for make the redirect page configurable – #306662: Add redirect option to site-wide contact forms.
Requests have their query parameters overridden by RouteProvider::getRouteCollectionForRequest() (here) when a route collection is matched in the cache. This is problematic if the cache entry was saved during a subrequest which alters the original request, specifically DefaultExceptionHtmlSubscriber, which sets two internal query parameters (_exception_statuscode and destination) for the error route.
This is problematic in so far as it's not intuitive behaviour (though this dates back to some early pre-8.0 work; see #2480811: Cache incoming path processing and route matching) but more importantly that the query parameters of later requests are overridden with those in the cache. For a form submission, this would mean the destination is overridden and incorrect, but in the case of a jsonapi path, it also means you get:
Drupal\\Core\\Http\\Exception\\CacheableBadRequestHttpException: The following query parameters violate the JSON:API spec: 'destination', '_exception_statuscode'. in Drupal\\jsonapi\\EventSubscriber\\JsonApiRequestValidator->validateQueryParams()
For instance, a common pattern in OAuth/JWT workflows is that a client will make a request with an existing access token; if it's unsuccessful (e.g., returns 401 - see #2840205: Error messages/codes should be more helpful & match spec.) then the client will attempt to obtain a new access token with a refresh token grant, and retry the original request. In this case, the retried request will fail with the above exception against a jsonapi endpoint as the now-authorized request will have the non-JSON:API spec compliant query string added.
The query string recovery from cache has mostly to do with the private files controller; see notes below. However, this issue is sensitive to alterations to the Request object prior to the cache ID generation for the collection cache, earlier even than incoming path processing.
Current thoughts are to not cache the match if we're doing a subrequest (though we currently lack that context as that's information stored in the kernel) or set the format for json:api requests sooner, so as to keep the html exception handler from firing to begin with. Or, something else?
Adjust the route collection cache cid to include the query parameters stored on the Request object after early processing.
Subsystem maintainer/core committer review.
None
None.
None.
Not necessary?
I am still not sure if this is a bug or I am doing something in a way it's not designed, but it sure feels as a bug.
The issue basically is that I can't upload a file (big enough for this to be reproduceable) unless the upload ajax functionality finishes.
I tried this with 8.6.x (latest dev as of today), no PECL upload progress and disabled big_pipe for testing purposes. This happens on a brand new drupal install locally (no network issues whatsoever).
Steps to reproduce
1. Install blank drupal site
2. add a file field to a content type (basic page for example)
3. select a big file (I am trying with one of ~400mb)
4. Click save before waiting for the throbber to finish.
Expected:
The file to be uploaded
Result:
Node immediately saved without the file.
On the other hand, if you want until the ajax functionality finishes, it does work, so it's no php/local settings issue either.
See screengif of both the not working and working parts.
Let's say I have:
I should be able to return ['pid' => value] from the plugin, and do this:
my_paragraph:
-
plugin: get_pid
source: tid
-
plugin: sub_process
target_id: pidBut sub_process seems unable to handle this.
If you change * @requires extension yaml to * @requires extension nope in \Drupal\Tests\Component\Serialization\YamlPeclTest and run the test you'll see:
OK, but incomplete, skipped, or risky tests!
Tests: 40, Assertions: 0, Skipped: 7.
THE ERROR HANDLER HAS CHANGED!
Other deprecation notices (2)
1x: The "Drupal\Tests\Listeners\DrupalListener" class implements "PHPUnit\Framework\TestListener" that is deprecated Use the `TestHook` interfaces instead.
1x: The "Drupal\Tests\Listeners\DrupalListener" class uses "PHPUnit\Framework\TestListenerDefaultImplementation" that is deprecated The `TestListener` interface is deprecated.
Process finished with exit code 1
The problem is the test is marked as failed because THE ERROR HANDLER HAS CHANGED! is outputted from \Symfony\Bridge\PhpUnit\DeprecationErrorHandler::shutdown(). This happens when the error handler that's registered in \Drupal\Tests\Listeners\DeprecationListenerTrait::registerErrorHandler() is not removed.
None
None (hopefully)
None
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.
The machine_name migrate process plugins replaces all non alphanumeric characters with underscores. It would be great if that would be a bit more flexible. Concretely, for some machine names it makes sense to allow a period as part of the name which currently gets replaced.
The code that currently handles this is the following:
$new_value = preg_replace('/[^a-z0-9_]+/', '_', $new_value);
Add some configuration value to the plugin for this. Not sure whether the whole regular expression, i.e. [^a-z0-9]+ should be configurable or just the character range, i.e. a-z0-9_.
The documentation for \Drupal\user\UserInterface::setExistingPassword states that the $this is the return value:
/**
* Sets the existing plain text password.
*
* Required for validation when changing the password, name or email fields.
*
* @param string $password
* The existing plain text password of the user.
*
* @return $this
*/
public function setExistingPassword($password);
However, \Drupal\user\Entity\User::setExistingPassword does not return a value:
/**
* {@inheritdoc}
*/
public function setExistingPassword($password) {
$this->get('pass')->existing = $password;
}
I'll add a patch to the comments.
Entity reference fields internally use \Drupal\Core\Entity\Plugin\DataType\EntityReference, which extends \Drupal\Core\TypedData\DataReferenceBase. However, neither DataReferenceBase nor EntityReference have a way to clear its $target property. This leads to entity reference fields becoming stale as soon as the target entity changes.
See the following scenario:
$node_storage = $entity_type_manager->getStorage('node');
$node_type_storage = $entity_type_manager->getStorage('node_type');
$node = $node_storage->load(1);
echo $node->type->entity->label(); // Hello world!
$node_type = $node_type_storage->load('hello_world');
$node_type->name = 'Hello moon!";
$node_type_storage->save($node_type);
// Reference's "target" property is stale.
echo $node->type->entity->label(); // Hello world!
// Storage thinks node is unchanged so returns node with stale reference.
$node = $node_storage->load(1);
echo $node->type->entity->label(); // Hello world!
// Storage returns new copy of the node, so the reference target is unset and needs to be loaded.
$node = $node_storage->loadUnchanged(1);
echo $node->type->entity->label(); // Hello moon!
I was wondering if we should replace the property with a static cache that uses the target entity's cache tags.