#Needs issue summary update

More information was asked for 8 years ago and it has not been supplied. Due to lack of interest I am closing this issue.

If you are interested in this idea, open a new issue in the core issue queue and add this issue as a related issue.

For those using composer and cweagans/composer-patches, "sites/default/default.settings.php" may not exist at time of patching. In this case, we can patch the file before scaffolding at "core/assets/scaffold/files/default.settings.php".

Joining a new patch for this configuration.

It seems it doesn't save the default revision state from the settings, so it need some new logic, ill continue working on this.

The ideas project is being deprecated, moving this to core.

I suspect that there are existing issues for adding filters to the pages listed.

I merged the branch and worked on making it able to set the default for revision for product types.

I tested this on our environment and it seems to be working as expected.

This was partly changed in 🐛 Umami page.tpl.php breaks block placeholders Needs review which was similar but I think more problems were identified here.

@berdir just opened 🐛 Umami page template renders header regions multiple times Active too.

Bot has some cs nits:

FILE: ...pal11/core/tests/Drupal/KernelTests/Core/Field/FieldMappingStorageTest.php
--------------------------------------------------------------------------------
FOUND 1 ERROR AND 1 WARNING AFFECTING 2 LINES
--------------------------------------------------------------------------------
19 | ERROR | Missing member variable doc comment
29 | WARNING | t() calls should be avoided in classes, use
| | \Drupal\Core\StringTranslation\StringTranslationTrait and
| | $this->t() instead
--------------------------------------------------------------------------------

Rebased the MR that got previously reviewed in #111, #112
Also adding a patch file for cweagans/composer-patches usage

As #112 mentioned, there are a few outstanding questions left

robin.houtevelts → made their first commit to this issue’s fork.

Automatically closed - issue fixed for 2 weeks with no activity.

Definitely looks like a duplicate of 🐛 Access cacheability is not correct when "view own unpublished content" is in use Needs work , please reopen if not.

OK. I created an issue 📌 FileSystem::tempnam() should use realpath() instead of getDirectoryPath() Active so we can tackle that first.

Could we start by looking at how we would change \Drupal\Core\File\FileSystem::tempnam() to not use ::getDirectoryPath()?

::realpath() of the scheme would accomplish the same outcome.

Do we need more strict type checks for LocalStream?

If using ::realpath() no, just validate the return is not FALSE. This allows classes that may implement local storage, however not extend LocalStream (such as extending a 3rd party framework to interface with core) to still function.

Could we start by looking at how we would change \Drupal\Core\File\FileSystem::tempnam() to not use ::getDirectoryPath()?

Do we need more strict type checks for LocalStream?

Updated the title and IS to reflect that the code must be converted to use forced-colors rather than removed.

RE @longwave's comment, #6:

I suggest converting background image cases to mask-image or mask using the original (full-color) image and using the appropriate system-color as the background.

There are many examples of the technique in Claro. I linked to a couple in the IS.

What's the status of this issue?

I changed the tip notes in both the documentation guides.

In 90% of select query use cases you will have a static query. If in a critical performance path, you should use db_query() and friends instead of db_select() for performance reasons. Dynamic queries should be used if the query parts vary (to add WHERE conditions depending on the context, for example), if they should be alterable (to check node access permissions, for example), or if a query extender is used (to create a paged query, for example).

In 90% of the use cases you will have a static query. When performance is critical, query() should be used instead of select(). Dynamic queries should be used when the query parts vary, when they should be alterable, or when an extendable query class is used.

OK, setting back to NW.

Seems pretty straight forward.

The patch attached in this issue is not for this project.

diff --git a/context_metadata.info.yml b/context_metadata.info.yml
index 225c7ed..d7dad0b 100644
--- a/context_metadata.info.yml
+++ b/context_metadata.info.yml
@@ -2,7 +2,7 @@ name: 'Context Metadata'
 description: 'Allows site admins to setup Meta Data using Contexts module'
 package: Context
 type: module
-core_version_requirement: ^8 || ^9
+core_version_requirement: ^9 || ^10 || ^11
 dependencies:
   - context:context
   - metatag:metatag

This project's machine name is context_media, not context_metadata.

Furthermore, none of the existing releases is currently supported. Before any change, a new branch compatible with a supported Drupal release must be created.

An issue needs to describe what needs to be changed and why. A title is never sufficient.

Furthermore, since patches are no longer tested, a merge request is necessary.

An issue needs to describe what needs to be changed and why. A title is never sufficient.

Furthermore, since patches are no longer tested, a merge request is necessary.

The 8.x-1.x branch is no longer supported. Before doing any change, a new branch needs to be created.

An issue needs to describe what needs to be changed and why. A title is never sufficient.

Furthermore, since patches are no longer tested, a merge request is necessary.

I think that what reported in Introduction to Dynamic Queries → (or Introduction to dynamic queries → for Drupal 7) is the minimum which could be said without disagreements.
This issue suggests making the topic clearer, but there are different opinions on what the documentation should say.

Neither the Drupal 7 nor the Drupal 8+ documentation guide says that static queries could be used when code does not use extenders, as comment #11 📌 Document usage of static vs dynamic queries Postponed: needs info suggests. That could be a useful addition, if it is not already understood with they should be alterable.

I took a closer look and this is documented in the note-tip https://www.drupal.org/docs/8/api/database-api/dynamic-queries/introduction-to-dynamic-queries. It has been there since the page was created in 2017. It is also in the Drupal 7 documentation, added in Jan 2013.

If anyone want this is Coding Standards, then an issue should be opened there for discussion.

I think this is fixed.

Rolled into an MR.

I think the decision on whether this makes sense is valid when sites implement hook_user_format_name_alter, however those sites could simply turn it off?

I don't think we need tests here as we're just toggling on sorting - this should be tested elsewhere.

I don't think we need profiling here as the db query is simple.

Left some feedback and updated the title.

These tests

• Drupal\FunctionalTests\Installer\InstallerTest
• \Drupal\Tests\system\Functional\System\SitesDirectoryHardeningTest

are failing which look related.

Also hid a load of outdated patch files.

Created an MR from #194 so we can run ci pipelines.

kim.pepper → made their first commit to this issue’s fork.

I updated the MR so it's against 11.x. It works, but the code is just copy/pasted so it needs to be updated for modern coding standards. IS still needs updated as noted in a previous commit.

capysara → changed the visibility of the branch 711735-block-filter-category-11 to hidden.

capysara → changed the visibility of the branch 11.x to hidden.

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Feedback appears to be addressed.

I applied the suggestion and rebased the MR too.

hmm the new test that fails is the one that's being added so something is still wrong here.

There are more tests that are failing on the last test run. All in ChainedFastBackend.

The change however makes sense and it has good test coverage.

small code improvement needed

The test only job didn't fail, but reverting the fix causes the new test to fail - here's the failing job:

https://git.drupalcode.org/project/drupal/-/jobs/4790389

I do not recall any documentation page that gives hints about which type of queries a module should use by default. This issue is still actual.

Reading the comments in this issue, I gather there is no exact consensus on which type of queries should be used by default, though. A documentation page should report what the pros and cons for each query type are, without pushing toward a type or the other one.

I converted the test-only patch to an MR, it passes locally, maybe it will fail with 100 runs.

The < check is still in core and I don't think it would hurt at all to change that to <=

📌 Optimize last_write_timestamp writes in ChainedFastBackend Active means that when there is one cache write on a page, the two servers would have to be more out of sync for there to be a problem, but it's only 50ms which is will within NTP tolerance, so it only makes the problem less likely and doesn't eliminate it. I think therre might be an issue around to try to use something else (like a special cache tag) that doesn't rely on clock time.

Is this being ported to 10.5.x? Just noticed it's been in "Patch (to be ported)" for a couple months now.

godotislate → closed merge request !10087

Is this still relevant since 📌 Optimize last_write_timestamp writes in ChainedFastBackend Active ?

Is the button tag going in? See #40 and #43 above.

Patch in #80 worked well for me. I needed video and source tags and this patch enabled them. Thanks!

The work here is about the Drupal 7 form api page and Drupal 7 is EOL. The work on the list stopped in 2013 around the time Drupal 8 was released. And the issue summary refers to a page with no content. It not clear any more what variables need documentation.

Is there work to be done here?