This .module file is not needed.
Open the file, it is empty.
Delete it.
Delete it.
N/A
N/A
N/A
N/A
N/A
Currently in .htaccess, the index.php rewrite is:
RewriteRule ^ index.php [L]
This rewrite has worked well, but with one issue. It changes the %{REQUEST_URI} variable to "index.php", making it subsequently impossible to use Apache directives that rely on the %{REQUEST_URI} variable, either in the core httpd configuration or later in the .htaccess file.
For example, the following directive would fail to set the WIDGET variable to true if if a request was made for "/widget":
RewriteCond %{REQUEST_URI} (/widget)
RewriteRule ^ - [ENV=WIDGET:true]
The proposed resolution is to change the index.php rewrite directive to be:
RewriteRule ^(.*)$ index.php/$1 [L]
This leaves the requested path in %{REQUEST_URI}, where it can be used in subsequent directives.
I can't find the issue that added this, but from what I remember:
- the installer has a blocking cron run at the end - this makes it take longer and shows up in profiling, including via drush.
- we show a warning when cron hasn't run for X period of time.
- this used to happen immediately after installing
- to avoid the site from showing warnings just after install, we added a cron run to the end of the installer
- this was probably (not sure) before poormanscron was added to core
1. Remove the cron run from the installer and see if the warning even shows up any more now that poormanscron is enabled by default.
2. If the warning does show up, discuss some more.
After setup CKeditor5 as text editor in Drupal 10.3
i get this error
Undefined array key "status" in editor_form_filter_admin_format_submit() (line 257 of core/modules/editor/editor.module).
editor_form_filter_admin_format_submit(Array, Object)
call_user_func_array('editor_form_filter_admin_format_submit', Array) (Line: 129)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 67)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 597)
Drupal\Core\Form\FormBuilder->processForm('filter_format_edit_form', Array, Object) (Line: 326)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 638)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 53)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->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: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 741)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
1. Go to admin/config/content/formats page
2. Add a text format
3. Use CKeditor 5 as text editor
4. Save your changes
5. You will see a successful message for the text format and one error message with the warning 'Undefined array key'.
TBD
A coding standards issue, #3489416: Fix Drupal.Commenting.FunctionComment.MissingReturnComment in non-tests, was put back to 'needs work' because of out of scope changes in PHPSstan baseline. Those changes were caused by re-generating the baseline and thus there should not have been a change.
I think this happened in #3477634: Ensure run-tests.sh and PHPUnit CLI run with the same list of tests to be executed
On 11.x HEAD rebuild the baseline
See changes to the baseline.
Rebuild the baseline
Many hook_requirements implementations have dependencies that are not explicit, and are difficult to test due to a lack of dependency injection.
N/A
hook_requirements should be split into 3.
Modules that only interact with one phase can just move to the new hook or class (with #[LegacyHook] to support older core for contrib)
Modules that only interact with one phase per section can move each section to the appropriate new hook or class (with #[LegacyHook] to support older core for contrib)
Modules like system that have a lot of $phase == 'install || $phase == 'update' those blocks can be moved to a helper and accessed by both locations that need it.
How to accomplish this. Three phases.
hook_runtime_requirements can stay a hook, OOP hooks can already support it.
Create this hook.
Create this hook_alter.
hook_update_requirements can stay a hook, OOP hooks can already support it.
Create this hook.
Create this hook_alter.
hook_install_requirements can become a special service provider like class.
Create support for the new class.
We need to document what services can be injected in a follow up, for now keep the same restrictions hook_requirements install phase has.
Break up module requirements into their new respective locations.
Once this is complete deprecate hook_requirements not having the LegacyHook attribute, just like hook_hook_info, hook_module_implements_alter and all install time hooks we need the actual hook functions to stay around so contrib can support multiple Drupal versions.
Create Child Issues
Create hook_runtime_requirements #3490841: Create hook_runtime_requirements
Create hook_update_requirements #3490842: Create hook_update_requirements
Create hook_install_requirements Class #3490843: Create class to replace hook_requirements('install')
Create conversion issue for all 22 files implementing hook_requirements in core #3490845: [pp-3] Convert hook_requirements to new class or hook_update_requirements or hook_runtime_requirements
Deprecate hook_requirements #3490846: [pp-many] Deprecate hook_requirements
N/A
Many likely
N/A
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Root composer.json requires drupal/core-composer-scaffold 10.3.11 (exact version match: 10.3.11 or 10.3.11.0), found drupal/core-composer-scaffold[8.8.0-alpha1, ..., 8.9.x-dev, 9.0.0-alpha1, ..., 9.5.x-dev, 10.0.0-alpha1, ..., 10.5.x-dev, 11.0.0-alpha1, ..., 11.x-dev] but it does not match the constraint.There's an issue to support adding third party settings to sections: #2942661: Sections should have third-party settings, but it would be great to also support third party settings for individual components (blocks) within a section.
For example, modules like Block Class, Field Formatter Class, Panopoly or Fences Block use third party settings on block config entities to allow the user to add arbitrary CSS classes to a block. It seems that the only way to do this with a Layout Builder block is to modify the settings form for the individual block plugin you want to modify and store the configuration along with the other configuration for that block.
SectionComponent should implement ThirdPartySettingsInterface
N/A
N/A
Because there was an existing similar approach ($additional)), deprecations are added with full BC
Data model addition
N/A
This is part of #3252084: [meta] Remove support for IE11.
I'd like to remove IE11 support from Olivero, which will enable a radically simplified and maintainable codebase.
A couple things off the top of my head:
So exciting!
See #3483037: [META] Add return types to hook implementations
This is the last group of hooks in Hook classes to be updated.
grep "fileDownload\\\\.* has no return" core/.phpstan-baseline.php
Add array|int|null to the hook documentation. Add the same to hook implementations, or a narrower set where possible.
When you use a taxonomy field on the user registration form, it does not show on the registration form, but it does show on the user edit form.
The 'page' template variable in node templates duplicates 'view_mode' = full. We don't need two variables that equate to the same thing, so should deprecated $variables['page'].
Follow-up to #2584243: Make Drupal handle path aliases in a consistent and case-insensitive fashion on all database drivers
It is currently not possible to do a case-insensitive LIKE comparison on values with non-ASCII characters, SQLite needs to be compiled with the ICU extension for this:
(18) Case-insensitive matching of Unicode characters does not work.
The default configuration of SQLite only supports case-insensitive comparisons of ASCII characters. The reason for this is that doing full Unicode case-insensitive comparisons and case conversions requires tables and logic that would nearly double the size of the SQLite library. The SQLite developers reason that any application that needs full Unicode case support probably already has the necessary tables and functions and so SQLite should not take up space to duplicate this ability.
Instead of providing full Unicode case support by default, SQLite provides the ability to link against external Unicode comparison and conversion routines. The application can overload the built-in NOCASE collating sequence (using sqlite3_create_collation()) and the built-in like(), upper(), and lower() functions (using sqlite3_create_function()). The SQLite source code includes an "ICU" extension that does these overloads. Or, developers can write their own overloads based on their own Unicode-aware comparison routines already contained within their project.
Ref https://www.sqlite.org/faq.html#q18
TBD
One workaround may be to do UPPER(x) = UPPER(y) COLLATE NOCASE_UTF8, where NOCASE_UTF8 is the custom collation defined in the PDO driver.
SQLite does case-sensitive searching unless you specify COLLATE NOCASE when creating the database schema, or include COLLATE NOCASE in the select clause. MySQL and Postgres are case-insensitive by default. In the interest of uniformity, I propose that the SQLite driver include COLLATE NOCASE in all column creations by default, unless a local override is provided via the schema API. Here's a (very lightly tested) diff:
--- schema.inc (revision 1568)
+++ schema.inc (working copy)
@@ -181,6 +181,8 @@
if (empty($spec['not null']) && !isset($spec['default'])) {
$sql .= ' DEFAULT NULL';
}
+
+ $sql .= ' COLLATE NOCASE';
}
return $sql;
}I was looking into creating a lazy service, since I knew this was possible in the Symfony DI component. There isn't much documentation on this in Drupal (see #2514582: Document lazy services and fix script doxygen) though it would be easy to think this works the same as in Symfony, which would be incorrect.
Lazy services were first introduced in #1973618: DIC: Lazy instantiation of service dependencies (ProxyManager for "proxy services"), in which the Symfony approach of a compiler pass was passed over in favor of a custom ProxyBuilder and ProxyDumper. The reasoning in the IS was:
This is the same approach as Symfony documents, except instead of using the Ocramius ProxyManager library that Symfony recommends, we use a custom lightweight implementation, which is faster (e.g., calls the proxied object's methods directly rather than via reflection) but not as complete (e.g., doesn't proxy property access, only method calls, and doesn't proxy magic methods). We think that's a worthwhile trade-off, since Drupal services don't use public properties, magic methods, etc.: the whole point of a service is to be defined by an interface.
This approach was later found to be incompatible with contrib modules, as the execution order of operations in building and dumping he DI container meant contrib interfaces were not discoverable. #2408371: Proxies of module interfaces don't work introduced the requirement to manually create the proxy service, using a script shipped with core.
There are a number of issues, such as #2532126: [meta] Follow-up for #2408371: Fix various issues with proxy services, #2539494: Provide a nice error message when trying to run the generate proxy class script on uninstalled/missing modules, the above-linked documentation todo, and #2513336: Consider checking checksum of interfaces during container building for proxy services which is probably most significant, having to do with the generated proxies going stale.
The vast majority of this work (and isuses) were done/logged 6+ years ago. From a DX perspective, I've personally concluded that the benefit of creating a lazy-instantiated service in Drupal is more trouble/danger than it's worth.
Drupal's DI container differs from the upstream Symfony component in that it is serialized and dumped into the database. That introduces some significant challenges, but I'm optimistic that recent improvements in Symfony, paired with efforts in Drupal to come back closer to feature parity with upstream, might mean we can back out of the very Drupal-ized lazy service pattern. This would help site owners/developers, allow us to delete a lot of code from Drupal core, and make this less of a DX WTF.
If you have absolutely positioned blocks like we have on https://www.drupal.org/project/cookies, there is no good region on Olivero to place them. The footer region, for example, has a relative position, so the block position origin is the footer, not the body.
Add a new region "Outside", "Outside Page", "Body", ... ? which will be printed as a direct child of the body element.
Using nested paragraphs we ran into the the issue that the weights were calculated wrong, after drag and dropping a paragraph that contained other paragraphs. What was wrong about the weights was, that they had the same values.
This occurred because of
first, how the updateField behavior in tabledrag.js is handling ordering, assigning the max value when running out of values
case 'order':
{
var siblings = this.rowObject.findSiblings(rowSettings);
if ($(targetElement).is('select')) {
var values = [];
$(targetElement).find('option').each(function () {
values.push(this.value);
});
// only takes into account the values count on one level
var maxVal = values[values.length - 1];
// targetClass is field_name-delta-order and this function takes into account all values on every level
$(siblings).find(targetClass).each(function () {
if (values.length > 0) {
this.value = values.shift();
} else {
this.value = maxVal;
}
});
and second, of how the order class is set in theme.inc inside the template_preprocess_field_multiple_value_form function
function template_preprocess_field_multiple_value_form(&$variables) {
$element = $variables['element'];
$variables['multiple'] = $element['#cardinality_multiple'];
$variables['attributes'] = $element['#attributes'];
if ($variables['multiple']) {
$table_id = Html::getUniqueId($element['#field_name'] . '_values');
// setting it up like doesn't take into account that multiple values on the same content could have the same field name
$order_class = $element['#field_name'] . '-delta-order';
this leaves room for same name order errors, because we choose a popular name like 'field_body' for a paragraph field that contained other paragraphs.
Assigning a unique name to the order class using the unique table id instead of the field_name only, like
if ($variables['multiple']) {
$table_id = Html::getUniqueId($element['#field_name'] . '_values');
$order_class = table_id . '-delta-order';
The reason behind this approach is that the table id already contains the field_name and also adds a unique part if the content is already on the view.
Is this a good approach or have I missed something similar in the issue queue?
#3492582: Replace some of obj && obj.prop with optional chaining introduced a random fail because it made an incorrect change to ajax.js - the reason it made the change is that it looked like it was possible when it was not.
Make stopEvent more explicit about it's expectations in the condition. This also makes the return type always a bool and never undefined.
This issue is similar to #3487449: Prefer to replace some of typeof obj !== 'undefined' with optional chaining possibly.
Some of JavaScript checks object existence and checks property existence of this object with obj && obj.prop.
For example, checks settings object and its property exsitence with below code in the /core/modules/views/js/ajax_view.js.
if (settings && settings.views && settings.views.ajaxViews) {
If uses optional chaining expression, this code can makes code more shorter like below.
if (settings?.views?.ajaxViews)
Use optional chaining.
TBD
No.
No.
No.
Ingested t() strings are normally validated on input for XSS (as opposed to user input that's filtered on output)
For example in D7: https://api.drupal.org/api/drupal/modules%21locale%21locale.admin.inc/fu... calls to https://api.drupal.org/api/drupal/includes%21locale.inc/function/locale_...
This validation needs to be applied to all strings submitted for config translation.
Example STR:
1. add a second language
2. give user A permission 'translate configuration'
3. as user A go to /admin/structure/comment/manage/comment/fields/comment.comment.comment_body/translate
4. add translation and fill label textfield with payload
5. script will trigger if admin visits /admin/config/regional/config-translation/comment_fields in the target language
Analysis thanks to Gabor Hojtsy:
the call stack of ConfigTranslationListController::listing() goes to EntityType::getLabel() which is a (string) $this->label and $this->label is…. a TranslationWrapper
it is a TranslationWrapper but is not with an already translated string… basically it translates the entity type “Comment”, and because we got in XSS via the config translation UI, we got a resulting string that is not safe, even though t() adds results to safe markup
Issues related to this were reported multiple times in the Drupal 8 security bug bounty program, including:
https://tracker.bugcrowd.com/submissions/5784d8a9dc93ce674776af30bf97f49...
https://tracker.bugcrowd.com/submissions/672a7ac983d1d6e554114e2f287824a...
credit to users:
JvE
grisendo