I've spotted this issue while trying to vacuum sqlite3 database (it grew to over 440 Mb), while sqlite3_analyze reported only 20 Mb of data and over 95% of freelist. Upon vacum, sqlite3 reported `Error: no such collation sequence: NOCASE_UTF8`. Apparently NOCASE_UTF8 is custom collation for PDO driver, but it is invalid in sqlite3. Simple replacing NOCASE_UTF8 with NOCASE on db file solves the issue. This likely affects auto vacuum and in the result db file gets really huge with time.
More info here: https://bioinfoexpert.com/2019/02/28/investigate-reduce-the-size-of-drup...
Also reported in https://www.drupal.org/project/drupal/issues/2462175#comment-12991687
SQLite driver should use COLLATE NOCASE instead of PDO custom collation (COLLATE NOCASE_UTF8)
[meta] Priorities for 2022-06-01 release of Drupal 7
Assorted todo lists carried over from #3216978: [meta] Priorities for 2021-12-01 release of Drupal 7
PHP 8.1 compatibility fixes are top priority for the next release.
These are not necessarily in priority order.
For consideration
- #3071997: Backport to D7 - inclusion of the announce project in D7 core - see also:
- #3206643: Project messaging channel in core and linked issues
Issues which have had recent activity, and are RTBC.
Simple Fixes:
- #2884171: The drupal_render() function could use a bit more protection May need to add logging for developers.
- #2994212: field_sql_storage_field_storage_load does use an unnecessary sort in the DB leading to a filesort Another field storage issue, marked as major with patch by Fabianx that still applies to D7, wile D9 patch needs work.
- #674354: CSS selectors get overridden by narrower selector at style.css when using Seven Simple fix, moves inline with D8 having more specific selectors.
- #1973278: Error in image_styles of image.module on database update Simple fix, does it really need a test?
- #2492191: Remove "Crawl-delay" in robots.txt Simple fix. For parity with D8/9 this should probably be committed to D7 although taking this out of D7 now seems like a big change at such a late stage; users who want to change Crawl-delay will already have done this. The patch itself is trivial so marking RTBC for a D7 core committer to decide whether to commit or close this.
- #920840: Broken images displayed and PHP notices when file/image field values are missing
- #2871459: Simpletest does not reset the $theme* globals
- #2218647: [D7] Undefined property: stdClass::$nid in node_tokens()
- #2830428: Fix behaviour of entity_load when passed ids with a trailing dot
- #3026560: After upgrade to 7.63, 8.6.7, or 8.5.10 still get TYPO3 phar error for drush
- #3182785: PHP 7.4 notice for /modules/system/system.admin.inc A simple fix that could possibly be improved.
- #3255713: [D7] Login fails and no warning is issued if cookies are not enabled This is a D7 backport of #2946: Login fails and no warning is issued if cookies are not enabled, an 18 year old issue that was marked as major and committed to drupal 9.3.x in June 2021.
- #2790857: Log completely unusable when an entry has corrupt serialized data (D7)
- #3281663: D7 backport: Fix htaccess files for PHP 8
- #3266018: Backport Make core aware of Nginx and PHP-FPM to D7
- #2112325: Warning: gzinflate(): data error in drupal_serve_page_from_cache() (line 1617 of /includes/bootstrap.inc).
- #3212398: [D7] Field API assumes serial/integer entity IDs, but the entity system does not
- #2828455: User mail token PHP notices for anonymous
- #3166668: PHP7.4 and empty entity_keys for taxonomy term result in notices
- #2594955: [D7] Duplicate HTML IDs are created for file_managed_file fields
Important Fixes:
- #1374090: Editing a comment still changes creation date Patch in comment #100 is 6 years old and appears to solve the problem. Comment #112 confirms patch looks good and to be deployed on drupal.org website.
- #1705618: Double click prevention on form submission Important to prevent double submission of forms, creating duplicate nodes, etc. Must clear browser cache to take effect.
- #1899126: [D7] Add wrappers to fix permission checks Required for POSIX filesystem. Fixed in D8? @orlitzky: "I'm just going to keep updating the patch for drupal-7.x for the rest of my life.""I'll keep posting patches until I don't have to any more."
- #1951408: Core Update manager doesn't correctly handle "status" UPDATE_NOT_CHECKED Includes D7 core patch in comment #16 that passes tests and is RTBC. Required for update_advanced module that is used by 2,700 sites. Does not appear to be relevant to D8/D9.
- #1978176: Build menu_tree without loading so many objects @joseph.olstad: "... the performance improvement is huge! .. After several years I see no credible reports of an issue with this patch"
- #2418755: Path alias filter by system path includes 6 year old patch for D7 in comment #1 that has been RTBC and without the patch "it's very hard to find alias which contains few slashes in path."
- #2431283: Cron CSRF vulnerability Security hardening fix. Fixed in D8. Fabianx comment in #31, just before last patch.
- #2550519: Crypt::randomBytes()/drupal_random_bytes() doesn't actually return cryptographically secure random bytes Issue is 6 years old, priority was set as "critical", still needs work.
- #2752783: [D7] file_unmanaged_move() should issue rename() where possible instead of copy() & unlink() Important fix. Mcdruid urging commit. @joseph.olstad: "D8 has this already. It is a good idea."
- #2783153: [D7] Convert drupalSettings from JavaScript to JSON, to allow for CSP in the future FabianX said it looks good, has updated tests
- #2891346: tableheader.js: Source: call to eval() or related function blocked by CSP Another content-security-policy issue.
- #2970929: [D7] Support X-Forwarded-* HTTP headers alternates Important backport for reverse proxies and load balance.
- #3176634: [D7] node_access filters out accessible nodes when node is left joined Issue identified as major. Fixed in D8 with D9 fix pending. Backport to D7 patch from 2016-March-9
- #3210388: Potential dataloss when opting in to "Avoid field storage write when field content did not change" and changing the bundle type of an existing entity
PostgreSQL performance improvements (backports from D8):
- #3265837: Backport DatabaseSchema_pgsql::fieldExists() improvements
- #2823488: Backport DatabaseSchema_pgsql::queryTableInformation() improvements
- #3265842: Backport DatabaseSchema_pgsql::findTables() improvements
- #2370593: Database::tableExists optimization for PostgreSQL
Unsorted Fixes:
- #498752: Partial word search for Drupal 7 Includes working patch from 5 yrs ago. Was closed as won't fix feature request. Now that a similar feature is proposed for D9 core #103548: Partial Search in Drupal Core maybe it's worth considering.
- #822128: "Textarea + summary" widget broken when field allows multiple values (followup) and associated JavaScript uses fragile selectors Has been committed to Drupal 8 and 9. Includes patch for D7 in #39 that is RTBC.
- #2539478: Allow image fields to use any extensions the current image toolkit supports (instead of hard-coding jpg, png and gif only) Adds svg to allowed extensions for image fields.
- #2819535: x-content-type-options nosniff ignored for anonymous cached pages
- #3017095: Clean up .htaccess and web.config file protection likely needs to go into D9 first
- #111702: Set fixed "from:" and add "Reply-to:" to comply with DMARC
- #965078: HTTP request checking is unreliable and should be removed in favor of watchdog() calls Needs work and needs CR
- #1328696: Problem with _drupal_wrap_mail_line and attachment files Attachment of docx file or files with long names results in email that is not correct. Fixed in D8, backport for D7 has patch.
- #3017522: D7 - Verify peer on HTTPS if cURL available (but be careful of built-in cert bundles in the codebase) Verifies SSL certificates in OpenSSL connections (Critical)
- #139015: breadcrumbs wrong on dblog event detail pages Issue seems in good shape, needs a bit of work as of Aug-4
- #691932: Add hook_field_schema_alter()
- #1992010: Reverting to revisions prior to addition of field translations is broken Issue is 9 years old, marked as critical and has patch that is RTBC and passes automated tests. Are tests sufficient?
- #1158322: Add backtrace to all errors
Move language negotiation prefix logic update to ConfigurableLanguage
Follow-up to #2403229: language.negotiation configuration can have overrides bleed in
Problem/Motivation
We should move language_negotiation_url_prefixes_update()
logic to a static method in ConfigurableLanguage so it can be reused and remove language_negotiation_url_prefixes_update()
.
Proposed resolution
Move logic to a static method in ConfigurableLanguage.
Remove language_negotiation_url_prefixes_update()
Remaining tasks
Create a patch
User interface changes
None.
API changes
The following global function is removed:
language_negotiation_url_prefixes_update()
Use ConfigurableLanguage::updateAllUrlPrefixes() instead.
Missing translations revisions
Since September in our site some nodes are disappearing. We had 8.5.X but now we have latest core version 8.6.2.
We have multilingual site and there are more than 10 persons adding and editing content and the same time.
Content that have problems: is translatable and working with revision system.
We have seen that node_field_data, node__body and other node field registers are deleted, but they are in revision tables.
No logs and no errors in watchdog, no deleting actions from editors, only disappear "node data" from database but not "node revision data".
What are the steps required to reproduce the bug?
We don't know why this happens and how to reproduce. Things to be in mind:
- Only happens in office hours, maybe problem is related with multiples access and same time.
- Only happens in content with a lot of editions, we have old content types with a lot of nodes with no problems.
- Only happens with translation entity, never happened with source translation.
We use following sql code to get orphans revisions:
SELECT distinct nfr.nid, nfr.langcode, nfr.vid
FROM node_field_data nfd
LEFT JOIN node_field_revision nfr ON nfd.nid = nfr.nid
where nfd.langcode != nfr.langcode
AND nfr.langcode NOT IN (
SELECT nfd2.langcode
FROM node_field_data nfd2
WHERE nfd2.nid = nfd.nid
)
AND nfr.vid = (
SELECT nfr2.vid
FROM node_field_revision nfr2
WHERE nfr2.nid = nfr.nid
AND nfr2.langcode = nfr.langcode
ORDER BY nfr2.vid DESC
LIMIT 0,1
)
ORDER BY nfr.nid DESC;
We have checked crons, code, a lot of process and we didn't get anything.
We have tried changing php max_input_vars to 3000 too but with no luck.
Any ideas?
Installer tests fail if contrib driver hides database credentials form fields
Problem/Motivation
If a contrib driver sets database credentials fields to 'hidden' in the installation form, Installer tests fail because Mink cannot find the fields to be set.
Proposed resolution
\Drupal\Core\Test\FunctionalTestSetupTrait::installParameters()
should get the correct form fields used by the driver before passing these into submitForm.
Remaining tasks
Rework patch
User interface changes
none
API changes
none
Data model changes
none
Install profile is disabled for lots of different reasons and core doesn't allow for that
Problem:
Issue summary:
NOTE: if you are trying to solve this novice issue, the plan of attack is at http://drupal.org/node/1170362#comment-5050480. We need a simple patch that takes most of http://drupal.org/node/1170362#comment-5011400 but instead of hiding the warning when a profile is not found, it displays its label as "Unknown").
There are multiple issues with install profiles, both within Drupal 7 and on upgraded Drupal 6 sites, these all end up with the same symptom: "Undefined index: distribution_name" due to system_requirements().
- Drush 3 and dependencies
- When profiles were made into modules, the modules the profiles need were put in
dependencies
. Unlike other modules, however, these are not real dependencies: your system might still work if you disable some. Like, installing the standard profile then disabling overlay module.This bug was discovered in #820054: Add support for recommends[] and fix install profile dependency special casing however fixing it would have required an API change for install profile developers, so that issue is only marked against Drupal 8, and workarounds were put into all code dealing with module dependencies to special case profiles instead.
Those workarounds were put into Drush 4/5 as well, but not Drush 3, which is still in use. So any site that runs drush updb with Drush 3 will have its install profile disabled by drush.
There's nothing that can be done about this in drush 3, and the bug is in core, so this issue tried to fix that.
- update.php
- sun's patches above demonstrate that just running update.php on D7 can disable your install profile, due to some weird things going on in _system_rebuild_module_data()
- Sites upgrading from Drupal 6 to a different install profile
- In Drupal 6, install profiles were 'run once', this meant that you could make a custom install profile for a site, install it, then never touch the install profile again (including when upgrading). When install profiles became required (half-)modules in Drupal 7, support for this was completely removed - if you install with a profile, we're currently requiring you to upgrade the specific profile you installed with through every possible future version of Drupal core. #1242956: Allow install profiles to be switched starts to discuss this, but since this blocks the upgrade path from D6 it's probably a legitimate bug here too
.
Proposed solution
There are a couple of ways to fix this, and they may be contradictory.
sun's patch started work on automatically ensuring the install profile is enabled every time _system_rebuild_module_data() is called. This would fix install profiles that have been disabled by drush 3 or update.php
However, there is no straight bug fix solution for the situation where a site is no longer using an install profile. For this we could either start allowing people to explicitly disable an install profile, or just make the system tolerant when none is found in the system (for example setting the site to use the 'minimal' profile which should never have any runtime code added to it).
To minimize the number of new comments asking for it, here's a work-around for current Drupal 7 users: You need to enable the profile used to install Drupal by updating the system table. For example: UPDATE system SET status=1 WHERE name='standard';
will enable the Standard profile. If you don't know which profile was used, just use 'standard'.
watchdog() does not type its array arguments
Problem/Motivation
If a third argument is passed to watchdog() that is not NULL or an array, the dblog page at admin/reports/dblog fails with a fatal error. This is because bad data is saved in the serialized 'variables' column in the watchdog table, and is not checked before passing to t() in dblog_overview()
Proposed resolution
Type hint the third argument to watchdog() as array.
Remaining tasks
None. Documentation has now been added, and a fix is committed to D8.
User interface changes
No UI changes.
API changes
Any calls to watchdog() that want to set a $severity level, but do not have $variables arguments for t() interpolation, have to pass array() instead of NULL as the third argument to watchdog().
No API changes. watchdog() will now throw an error if anything other than an array or NULL is given as the 3rd argument to the function.
Original report by cam8001
Recoverable fatal error: Argument 2 passed to t() must be an array, string given, called in /var/www/example.com/modules/dblog/dblog.admin.inc on line 265 and defined in t() (line 1451 of /var/www/example.com/includes/bootstrap.inc
A contrib module passed some bad arguments to watchdog(), the data was saved to the watchdog table, then passed to t() for display at admin/reports/dblog. t() fails on the bad data, and now I cannot view logs at admin/reports/dblog.
I can get around the issue and restore the page's functionality by deleting the offending rows from the watchdog table.
Blocks are created with a default weight of null, not 0
Problem/Motivation
Place a block, but don't submit the block admin form afterwards (or use the experimental Place block module to do it).
The weight of the block is NULL, not 0 in the config, such as:
uuid: d8055768-1043-4b42-9eab-92146e3cc38b
langcode: en
status: true
dependencies:
config:
- views.view.who_s_new
module:
- views
theme:
- bartik
id: views_block__who_s_new_block_1
theme: bartik
region: sidebar_second
weight: null
provider: null
plugin: 'views_block:who_s_new-block_1'
settings:
id: 'views_block:who_s_new-block_1'
label: ''
provider: views
label_display: visible
views_label: ''
items_per_page: none
visibility: { }
Proposed resolution
Add a hidden (or value?) form input to BlockForm with a default of 0 for new blocks. Make sure block form validation checks that it's an integer.
Possibly, add support for query string to set the weight so it's possibly to position a new block relative to other blocks.
Remaining tasks
Write a patch and tests
User interface changes
none
API changes
none
Data model changes
none
Module uninstall validators are not run on config import
Problem
#2278017: When a content entity type providing module is uninstalled, the entities are not fully deleted, leaving broken reference introduced a new module install validator API, however configuration import does not yet check whether the validators pass. If they fail, module uninstall will throw exceptions.
Proposed resolution
- Run module install validators from config import.
- In order to avoid some checks like for configurable fields to be run twice, we want to extend the validator API to support running in two modes: excluding configuration-based checks or not.
Remaining tasks
Do.
User interface changes
-
API changes
- Extend the module uninstall validator by an optional parameter to exclude configuration-based validation checks. No BC break here (addition only).
EntityMalformedException: Missing bundle property on entity of type node in entity_extract_ids() line 7929
Hi.
I have a content type with a file field.
I have a custom module with a hook form alter.
With hook form alter I add a extra submit function to node form.
$form['actions']['submit']['#submit'][] = 'anexar_aplicacion_submit';
In the submit:
function anexar_aplicacion_submit(&$form, &$form_state) {
$reto_nid = $form_state['values']['reto_nid'];
$aplicacion_nid = $form_state['node']->nid;
$reto = node_load($reto_nid);
$reto->field_aplicaciones[LANGUAGE_NONE][]['target_id'] = $aplicacion_nid;
field_attach_update('node', $reto);
field_attach_presave('node', $reto);
entity_get_controller('node')->resetCache(array($reto->nid));
}
Error is thrown when I create a node of this content type, with the file.
Error is not thrown when I create a node of this content type, without the file.
Error:
EntityMalformedException: Missing bundle property on entity of type node in entity_extract_ids() line 7929
Thank you.
Use CKEditor 5's native <ol type> and <ul type> UX
Problem/Motivation
We "solved" the problem of supporting <ol type>
and <ul type>
by using the SourceEditing
functionality for that.
But in CKEditor 5 32.0.0, they've added a native UX for setting the list type:
Which means that rather than having to edit HTML by hand, the content creator can now do that through the UI! But unfortunately, it currently always generates <ol style="list-style-type:SOMETHING">
and <ul style="list-style-type:SOMETHING">
, so we cannot use this.
This is blocked on https://github.com/ckeditor/ckeditor5/issues/11615.
It'd also improve the upgrade path because these attributes would no longer have to get set through the SourceEditing
functionality.
Steps to reproduce
N/A
Proposed resolution
TBD
Remaining tasks
TBD
User interface changes
TBD
API changes
None.
Data model changes
None.
Release notes snippet
TBD
Fix a typo in Help message on ckeditor5.module
While checking the ckeditor5 core module, I noticed that in the ckeditor5.module the word "be" is repeated (46:381).
Changing this will have no effect on any code, just a simple typo fix in the help message displayed to the users.
Fix a comment typo in BlockTest
While checking the block core module, I noticed that in the core/modules/block/tests/src/Functional/BlockTest.php
file the word "the" is repeated (166:46).
Changing this will have no effect on any code, just a simple typo in a comment.
Seven theme: Fix text alignment on form submit buttons
The buttons don't look consistent. I propose we apply either text-align: left
or text-align: center
for both buttons.
Fix typo in assertion on ConfigImportUITest
While checking the config core module, I noticed that in the core/modules/config/tests/src/Functional/ConfigImportUITest.php
file the word "theme" is repeated.
Field Groups marked as required are missing red asterisk
Problem/Motivation
When using the field group module, groups that contain required fields are not styled to have the red asterisk to denote that group has required fields. The form-required class is in the mark, but no styles for it.
Steps to reproduce
- Added fields to a node that are required
- Create fields groups
- Ensure the Mark group as required if it contains required fields. option is selected for a group
- Observe when creating content that the red asterisk is missing
Proposed resolution
Update the styles to account for this. The core/themes/claro/css/components/form.pcss.css has some styles already for the form-required class, but they are too specific. I would think making this style selector less specific would fix it, but there could create issues if the after pseudo element is intended for other use.
Disable CKEditor 5's automatic link decorators (in Drupal filters should be used instead) + explicitly test manual link decorators
Problem/Motivation
Discovered in #3246169: Embedded media are not linkable through UI; already linked embedded media are unlinked (data loss!).
See https://ckeditor.com/docs/ckeditor5/latest/api/module_link_link-LinkConf... and https://ckeditor.com/docs/ckeditor5/latest/api/module_link_link-LinkDeco....
Try this by applying
diff --git a/ckeditor5.ckeditor5.yml b/ckeditor5.ckeditor5.yml
index f6eaf90..80467ef 100644
--- a/ckeditor5.ckeditor5.yml
+++ b/ckeditor5.ckeditor5.yml
@@ -224,6 +224,9 @@ ckeditor5_link:
ckeditor5:
plugins:
- link.Link
+ config:
+ link:
+ addTargetToExternalLinks: true
drupal:
label: Link
library: ckeditor5/ckeditor5.link
Now every link you create that matches ^(http|//)
will get target="_blank" rel="noopener noreferrer"
applied.
This feature makes a ton of sense in CKEditor 5, where the generated HTML is the served HTML. But it does not make sense in Drupal, where we prefer not storing (hardcoding) such decisions in the database, and instead filter it on output, using the filter system.
For this example, the Drupal equivalent is https://www.drupal.org/project/extlink.
Steps to reproduce
See above.
Proposed resolution
- Disable CKEditor 5's automatic decorators entirely, both on server (done) and client (TODO).
- Add explicit test coverage for manual link decorators, for the
drupalImage
(done) anddrupalMedia
plugins in particular (TODO).
Remaining tasks
Discuss with CKEditor 5 team to determine best approach.Done. Conclusion: throwing an exception when automatic decorators are configured, both in PHP and in JS.Prevent automatic link decorators on server side.- Prevent automatic link decorators on client side.
Test coverage for automatic link decorators being prevented on server side.Test coverage for manual link decorators working with<img>
.- Manual link decorators working with
<img>
. - Test coverage for manual link decorators working with
<drupal-media>
. - Manual link decorators working with
<drupal-media>
.
User interface changes
None.
API changes
None.
Data model changes
None.
TermStorage::loadChildren returned elements are not sorted by weight, name
When I upgrade Drupal core from 8.4.6 to 8.6.16 I faced an issue in TermStorage::loadChildren.
I was using this function
:\Drupal::entityTypeManager()->getStorage('taxonomy_term')->loadChildren($parent_term->id());
for manging the website navigation by parent client relation . But after the upgrade the order was not by weight .
Adding the API page, someone else also faced the issue: https://api.drupal.org/api/drupal/core%21modules%21taxonomy%21src%21Term...
Adding a patch to fix this by adding :" ->sort('weight', 'ASC'); to the getChildren function.
Error on PHP8 during execution Database::closeConnection()
Problem/Motivation
After execution a batch operation on PHP8 we use Database::closeConnection() that should avoid the MySql gone away error after a long batch operation. But Drupal throw an error
WD php: Error: User-supplied statement does not accept constructor [error]
arguments in PDO->prepare() (line 544 of ../docroot/includes/database/database.inc). Error: User-supplied statement does not accept constructor arguments in PDO->prepare() (line 544 of ../docroot/includes/database/database.inc).
Steps to reproduce
Run some batch operation and then try to call Database::closeConnection() on PHP8
Proposed resolution
I would suggest to apply fix that check in __destruct() method if we have DB connection
public function __destruct() {
if ($this->needsCleanup) {
if (get_object_vars($this->connection)){
$this->nextIdDelete();
}
}
}
Fix a comment typo in common.inc
I noticed that in the core/includes/common.inc
file the word "it" is repeated (468:28).
Changing this will have no effect on any code, just a simple typo in a comment.