If a non-empty item is appended or removed on a field item list, the parent will not be notified about the change. If you have some listener logic in ContentEntityBase::onChange(), which is expecting to be called for the field on which an item is appended/removed, then this logic will not be triggered at all.
Notify the parent when appending/removing a non-empty item.
The Syndicate block provides a default configuration:
public function defaultConfiguration() {
return [
'block_count' => 10,
];
}
However this value is unused and there is also no form to configure this value.
Remove this from the block configuration and schema. See #2251789: ForumBlockBase::defaultConfiguration() uses a seemingly defunct 'properties' key for inspiration on a similar issue.
Follow-up to #3048848-18: Syndicate block outputs wrong feed URL
frontpage view could change URL for RSS feed but \Drupal\node\Plugin\Block\SyndicateBlock expects that URL always rss.xml
See build() method https://git.drupalcode.org/project/drupal/-/blob/9.0.x/core/modules/node...
1) add check the view exists and retrieve feed URL from the view
2) not rendering the block when view missing
3) discuss to add setting for URL
agree on implementation
patch/commit
TBD
no
no
no
Tests started failing with the following error:preg_match(): Unknown modifier 'w'
With the stacktrace
/data/app/core/modules/media/src/OEmbed/Endpoint.php:155
/data/app/core/modules/media/src/OEmbed/UrlResolver.php:135
/data/app/core/modules/media/src/OEmbed/UrlResolver.php:167
/data/app/core/modules/media/src/Plugin/media/Source/OEmbed.php:246
/data/app/core/modules/media/src/Entity/Media.php:258
/data/app/core/modules/media/src/Entity/Media.php:156
/data/app/core/modules/media/src/Entity/Media.php:392
/data/app/core/modules/media/src/MediaStorage.php:27
/data/app/core/lib/Drupal/Core/Entity/EntityBase.php:339
/data/app/profiles/custom/my_profile/tests/src/MediaTestTrait.php:146
Where line 146 is saving a video media entity.
This is caused by Chainflix having endpoints https://(m|www).chainflix.net/video/?* and https://(m|www).chainflix.net/video/embed/?*
The regex in matchUrl uses pipe characters as the regex delimiters.
Save a new video media entity
Fix the regex replacement in \Drupal\media\OEmbed\Endpoint::matchUrl
Currently, when https://oembed.com/providers.json is fetched to generate a list of available oEmbed providers, there is no opportunity to alter the list of providers.
This would be useful in scenarios such as 1) Peer Tube and 2) oEmbed providers that may be organization-specific. Peer Tube is a decentralized video platform. The user can search videos across multiple instance of PeerTube with different domain names. Re custom oEmbed providers, the University of Nebraska-Lincoln hosts its own video service, which will soon support oEmbed. This functionality is needed by this organization.
Provide hook_oembed_providers_alter(). (Media already provides hook_oembed_resource_url_alter()).
None.
Adding hook_oembed_providers_alter().
None.
TBD
I have studied the code from the oEmbed system in the core and I have discovered that it is based on the list provided by https://oembed.com/providers.json
This is a good list to start but I am wondering how to add a provider to this list?
You can host a new file with the additional services and change the settings "oembed_providers_url". But this method is really complicated to just support more providers.Moreover I am creating this issue in order to support PeerTube which is a decentralized video platform. The user can search videos across multiple instance of PeerTube with different domain names. Such a complicated way to support a new provider is just impossible for a simple contributor.
In order to resolve this problem:
- The user should be able to override the default URL. The issue already exists for another reason: #2999018
- We should be able to alter the provider list by using a hook. What do you think about adding an alter call in the getAll function from Drupal\media\OEmbed\ProviderRepository?
Meta for triage credit, please note: you only need to add a comment for one issue that was triaged and closed, not every one.
Remember to add the tag 'Bug Smash Initiative' to issues that are triaged.
If PHP throws a FATAL error, a 200 response will be returned.
This could mean that the 200 'OK' response gets cached by a browser, a reverse proxy, or a CDN.
I was sure PHP could return a 500 is maybe display_errors were turned off, but from testing this wasn't happening for me.
If we set the status code to 500 in index.php, before any other code is run, we can ensure that PHP will return a 500 response code for FATAL errors. All other cases will be handled by a Response object, so will have the correct/intended status code
To reproduce:
1. Create an AJAX request to your drupal application
2. When handling the AJAX request, cause a TypeError
Expected behaviour:
The AJAX request returns with a 500 (bad request) http status code
Actual behaviour:
The AJAX request returns with a 200 (ok) http status code
Context:
Ubuntu 16.04.2 LTS
Php 7.1.5
Apache 2.4.18
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:
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.
Meta for triage credit, please comment and link to issues you triaged and closed.
If we go to node view we receive non catchable MethodNotAllowedException.
Step to reproduce:
1. Install module rest.
2. Install module language.
3. Install module page_manager(Seams that this step can be excluded).
4. Create some language.
5. go to /admin/config/regional/language/detection and check Account administration pages.
6. Go to user edit page and set some language in "Administration pages language".
7. Go to node view.
You will receive:
Symfony\Component\Routing\Exception\MethodNotAllowedException: in Symfony\Component\Routing\Matcher\UrlMatcher->match() (line 97 of vendor/symfony/routing/Matcher/UrlMatcher.php).
Drupal\Core\Routing\UrlMatcher->finalMatch(Object, Object) (Line: 152)
Symfony\Cmf\Component\Routing\NestedMatcher\NestedMatcher->matchRequest(Object) (Line: 258)
Symfony\Cmf\Component\Routing\DynamicRouter->matchRequest(Object) (Line: 185)
Symfony\Cmf\Component\Routing\ChainRouter->doMatch('/node/212', Object) (Line: 155)
Symfony\Cmf\Component\Routing\ChainRouter->matchRequest(Object) (Line: 89)
Drupal\Core\Routing\AccessAwareRouter->matchRequest(Object) (Line: 138)
Drupal\Core\Routing\AccessAwareRouter->match('/node/212') (Line: 139)
Drupal\user\Plugin\LanguageNegotiation\LanguageNegotiationUserAdmin->isAdminPath(Object) (Line: 109)
Drupal\user\Plugin\LanguageNegotiation\LanguageNegotiationUserAdmin->getLangcode(Object) (Line: 191)
Drupal\language\LanguageNegotiator->negotiateLanguage('language_interface', 'language-user-admin') (Line: 136)
Drupal\language\LanguageNegotiator->initializeType('language_interface') (Line: 223)
Drupal\language\ConfigurableLanguageManager->getCurrentLanguage() (Line: 84)
Drupal\language\EventSubscriber\LanguageRequestSubscriber->onKernelRequestLanguage(Object, 'kernel.request', Object) (Line: 116)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.request', Object) (Line: 120)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 62)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 62)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 53)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 103)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 82)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 55)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 632)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
Database drivers that extend another database driver have to add the line with something like: include_once dirname(__DIR__, 8) . '/mysql/src/Driver/Database/mysql/Connection.php';. When this line is not added, the database driver will fail the installation proces. The extending database driver is then using a class that is not autoloaded and therefor does not exist.
The include_once only works when the module with the extending database driver is in the same level in the directory structure. This is not very practical for sitebuilders. It is also not to the standard Drupal Core would like its code to be.
Example database drivers that extend another database driver are: https://www.drupal.org/project/mysql56 and https://www.drupal.org/project/pgsql_fallback.
Improve the autoloading for the parent database driver during installation.
TBD
None
The method Drupal\Core\Database\Database::findDriverAutoloadDirectory() has been deprecated are will be removed in Drupal 11. The method has been replaced by Drupal\Core\Database\Database::getDriverAutoloading().
The method Drupal\Core\Database\Database::determineDriversAutoloading() has been added and it returns autoload data for all available database drivers.
None
TBD
When cancelling a user account and reassigning the author of revisions, a lot of additional revisions are created and the 'revision_translation_affected' field doesn't seem to be retained.
Steps to reproduce:
The method Drupal\Core\Database\Database::convertDbUrlToConnectionInfo() in that there is the possibility the array key $query['module'] is not set. Only in D10 all database drivers live in a module, therefor it must be set. Also the connection class Drupal\\Driver\\Database\\{$driver}\\Connection no longer exists.
Remove and refactor the code of the method Drupal\Core\Database\Database::convertDbUrlToConnectionInfo().
TBD
None
None
None
TBD
There's currently a lack of clarity in the half a dozen methods on HTMLRestrictionsUtilities. \Drupal\ckeditor5\Plugin\CKEditor5PluginManager::getReadableElements() and \Drupal\ckeditor5\Plugin\CKEditor5PluginManager::getBlockElementList() should also be refactored out of there.
IMHO by far the clearest solution here is to stop treating this specially structured as an array. We already started doing that by introducing that utility class in the first place in #3216015: Generate CKEditor 5 configuration based on pre-existing text format configuration, where we added \Drupal\ckeditor5\HTMLRestrictionsUtilities::diffAllowedElements(). #3222852: <dl> <dt> <dd> by introducing "Manually editable HTML tags" configuration on Source Editing made it grow a lot, and just made it clear we really need better developer ergonomics around this — the risk of bugs is otherwise very high.
Therefore I think introducing a HTMLRestrictions value object would make this a lot less brittle, and far simpler to test:
final class HTMLRestrictions {
public static function create(string $string): HTMLRestrictions;
public function diff(HTMLRestrictions $other): HTMLRestrictions;
public function intersect(HTMLRestrictions $other): HTMLRestrictions;
public function toCKEditor5ElementsArray(): string[];
public function toFilterHtmlAllowedTagsArray(): string[];
public function toGeneralHtmlSupportConfig(): string[];
}
Seems like some quite significant changes have been encountered in #3220021: [meta] Ensure compatibility of Drupal 9 with PHP 8.1 (as it evolves).
Try testing D7 core with PHP 8.1
Make tests pass.
?
n/a
n/a
n/a
tbc
We are experiencing a new warning after migration to PHP 8.1:
Warning: Undefined array key "sequence_name" in DatabaseConnection_pgsql->query() (line 120 in /xxx/includes/database/pgsql/database.inc).
PHP: 8.1
Database: PostgreSQL 11
Drupal: 7.84
This warning was not present on PHP 7.3 / PostgreSQL 11.
It seems like that this is already fixed in D9, as the code here is:
core\lib\Drupal\Core\Database\Connection.php
case Database::RETURN_INSERT_ID:
$sequence_name = $options['sequence_name'] ?? NULL;
return $this->connection->lastInsertId($sequence_name);
However the code in D7 is following:
includes\database\pgsql\database.inc
case Database::RETURN_INSERT_ID:
return $this->connection->lastInsertId($options['sequence_name']);
It should be sufficient to implement the same change to D7 as it is in D9.
As a follow-up to #3167034-30: Leverage the 'loading' html attribute to enable lazy-load by default for images in Drupal core and elsewhere, let's add a UI to allow the loading attribute to be changed from the UI.
Add a new setting in the Image field formatter that allow users to select the loading priority.
By default settings are closed.
Expanded.
The result of migration_lookup would appear to be one of two things:
- successful lookup
- failed lookup
but that is not actually the case. It can be one of THREE things:
- A. successful lookup for a migrated item
- B. successful lookup for an item which the migration ignored
- C. failed lookup
In my use cases, B and C should be treated the same: there is no migrated record found in the migration. For example, in a migration of translations, I look up the original language migration:
mid:
-
plugin: migration_lookup
migration: mixed_video_as_link_url
no_stub: true
source:
- id
- revision_id
- content_translation_source/0/value
-
# Skip the row if the lookup returns nothing because the original
# migration skipped.
plugin: skip_on_empty
method: row
However, the migration_lookup process plugin returns different things for cases B and C:
- A: an array of destination IDs
- B: an array of NULLs, because the lookup migration map has NULLs in it
- C: an empty array
The problem is that skip_on_empty can't catch both cases B and C.
Currently, because of #2905929: skip_on_empty doesn't work if the value is an empty array, it can't catch case C. If we fix that bug, then it won't catch case B, because an array of NULLs will get considered as a single value, and an array of NULLs is not empty.
I don't see how the skip_on_empty plugin can handle both of these cases, even if we address its various issues (#3254356: [meta] skip_on_empty problems with arrays).
That plugin's concept of 'empty' should match PHP's, otherwise we're creating a WTF. So an array of NULLs should not be skipped if we fix #2905929: skip_on_empty doesn't work if the value is an empty array.
Either:
A. Build the skipping option into the migration_lookup process plugin
B. Add a new process plugin called 'skip_on_empty_lookup'
C. Add an option to the migration_lookup process plugin for it to return an empty array for all-NULL destination IDs
I'm leaning towards option C.
The files core/modules/migrate_drupal/tests/modules/migrate_state_finished_test/src/Plugin/migrate/field/FieldLeft.php and core/modules/migrate_drupal/tests/modules/migrate_state_finished_test/src/Plugin/migrate/field/FieldRight.php break PSR-2 and PSR-4 and cannot be autoloaded correctly.
Determine if they are even needed anymore.