@codebymikey

Support for this is already possible, mingsong's already linked to the relevant documentation in #3.

Any difficulty in implementation is likely down to the site builder's views configuration as the module passes all the relevant filters to the REST API URL to handle filtering.

Closing for housekeeping purposes.

codebymikey → created an issue.

codebymikey → created an issue.

A more refined views integration (with a variety of more views plugins) is available in 📌 Add support for File entities and full Views integration Needs work

@solideogloria

Would this also make it so that files will be marked temporary when the Entity Usage module says that there are no more uses? That's what I think should happen if the site has $config['file.settings']['make_unused_managed_files_temporary'] = TRUE;

Not currently, but it could theretically be easily added as a File entity pre-delete hook or equivalent, that does the appropriate checks for it.

However given how it's a major change in behaviour from how it previously worked, I'd recommend we add this functionality as a follow-up or separate issue hidden behind a configuration or something since the accidental loss of data is something we'd want to avoid where possible.

Fixing #3312198: Regression concerning the cache of private files is tricky because of PathProcessorFiles, which converts paths like system/files/path/to/private/file.txt to an internal path of system/files?file=path/to/private/file.txt.

From my findings, that doesn't seem to be the case if the file path is is within a folder such as 2022-10/test.txt, mainly because the current logic doesn't attempt to normalize the inbound URI path.

Here's a simplified patch that works for me, as I haven't had time to test the other patch to see if it breaks anything else.

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

Closing as this appears to be a duplicate of 🐛 Deprecated: Using ${var} in strings is deprecated, use {$var} Fixed

codebymikey → created an issue.

After this is merged, a 2.x branch needs to be created so that issue forks can be created from it.

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

codebymikey → created an issue.

Added a MR which uses an appropriate timecode based on the duration of the video.

I use Windows, and it's not been an issue as per some of the other related issues like #3064574: Multiline YAML with \r\n not being encoded properly → .

The presense of "\r\n" is a browser specific quirk (it always converts the submitted new lines to CRLF), but doesn't need it to be persisted that way.

The original issue was caused because the new code I implemented not accounting for if the query.get(startParam) was empty (I assumed passing a null into Date would've lead to an invalid date, but I guess not, so my bad guys!).

I believe exposing the initialDate property as a configuration is useful since a site installation might use the start query string for something else, and for most use cases the startParam is usually also the initialDate. I've created a new MR adding the functionality.

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

Added support for the graphicsmagick and imagemagick binaries. graphicsmagick is a newer and slightly faster fork, so it's checked for first, before falling back to imagemagick, and then the PHP extension.

The generated JPG files are slightly smaller but of similar quality.

Patch available here.

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

Thanks for the quick reply! Would it be possible to create a tagged release for it so we can target that version going forward?

codebymikey → created an issue.

Thanks for taking this up, I wasn't able to replicate the issue using the UI since the constraint validation stopped it from occuring.

I just came across the entity with the unpublish_state as it was (NULL), but not exactly sure how it got to that state. Just that it couldn't get itself out of the state.

Looking at the revision history, the state was as follows:

So it's possible the state was changed using a different mechanism that didn't check for validation constraints (not sure as there are no revision log messages for it).

Either way, in the event that an invalid transition is reached, the current error handling is such that it'll always clear the target state, and after the module returns -1, it'll be resaved with the now NULL target state and result in the loop.

I think the way to provide a test case for it is to change the moderation state directly rather than through the UI, so that the -1 cases can be properly tested for.

Created settings for debug/verbose logging:

codebymikey → created an issue.

The original issue might already be addressed by 🐛 Gin vertical toolbar submenu's overlap Active as I couldn't replicate the issue on there, so updating the issue to better support for Gin (by having a dedicated CSS file) as well as improving theming support by removing most of the inline styles and JS in favour of stylesheet inheritance via CSS custom properties in the form of --environment-indicator-background and --environment-indicator-color.

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

then why don't user password reset hashes and similar?

They probably do as well, but from my use case so far, user resets are rarely done, and not necessarily deterimental to the user experience enough since the user reset hash can be easily regenerated to give a different hash that won't match the questionable URI path, whereas asset hashes appears to always be the same even after a cache clear and can cause the rest of the site to be non-functional or appear broken.

One question I've had is whether we even need to base64 encode the SHA256 hashes in the first place? It's already URL safe as hexadecimals, and base64-ing it doesn't appear to make it more secure than it currently is, it just provides a slightly shorter string.

The issue is that most sites/modules rarely take translations into account, but there is a use case for it.
I think translations isn't something that should be handled on the templating level (given it's based on the whatever language is active at the time), and is precisely the reason the date_format config property is made to be translatable, and scales a bit better.

The additional code is merely to support the UI translation elements of things (which I feel is the best option for full translation support without reopening future issues), however if you're strongly against the addition of the UI elements, we can have it be a hidden translatable config that can be overridden by the site builder as necessary similar to how $config['image.settings']['allow_insecure_derivatives'] = TRUE; is used in core (the config exists, but there's no native UI to actually enable it).

The xxHash is an interesting one, I've created a quick 3v4L PHP snippet to showcase the outputs from the various hashing algorithms.

It appears xxh64 already provides a fairly short 16 character hexadecimal output as it's a 64-bit hash, so that seems like the way forward. I'll try putting in a MR for the changes in due course and see if the change breaks anything.

codebymikey → created an issue.

Work done so far in the MR provides a way to provide theme.json support in Drupal (it can be added as a theme.json file or the <theme>.gutenberg.theme.yml file.

But requires pulling in a bunch of WordPress code in in order to properly render and manipulate the blocks as WordPress does.
This provides the side effect of us essentially needing to reimplement a lightweight version of the wordpress filter system in order to get things to function as they should.

Updated the patch to address a bug which results in potentially thousands of revisions being created if the content editor happens to transition to the target moderation state before the scheduler is able to handle it.

It keeps failing and creating new revisions because:
1. It's unable to transition back to itself.
2. The target moderation state is set to NULL.

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

codebymikey → created an issue.

Following this change, the Original (full) image style is no longer visible in 3.x.

codebymikey → created an issue.

Provided a MR restricting the loaded image styles.

Not sure what happened, but the changes didn't touch or should break any of the functional JS tests.

It's now passing following a rerun without any specific changes, so it's something caused by upstream or Gitlab CI as I've experienced something similar in the past.

Created a PR addressing the issue.

codebymikey → created an issue.

After revisiting #3004425-58: Date formats with abbreviated month name (M) and ordinal suffix are not translated using context → , I believe the best option is to make the day format a config that can be translated by site builders based on the language.

This removes the reliance on core, and provides support for ordinals that might show up before the number rather than after.

Introducing the config allows us to further extend the translations/theming in the future.

Support for ordinal suffixes is a bit more complicated (e.g. https://www.omniglot.com/language/dates/welsh.htm), but providing some translation is better than using English ordinal text within a different language.

And for the more complicated ones, an ordinal dot could could be used.

Available reference: https://3v4l.org/jXP5l#v8.4.4

Test failures are due to a separate issue with functional JS.

On further investigation, it's actually not as straightforward as I thought as some languages don't support ordinal suffixes, and outright skip them. Using translations using the .po file doesn't accept empty strings as far as I'm aware.

https://en.wikipedia.org/wiki/Ordinal_indicator#Ordinal_dot

The only workaround to enforce the empty string is potentially something like this in your settings.php:

$settings['locale_custom_strings_cy']['date_ordinal_suffix'] = [
  'st' => '',
  'nd' => '',
  'rd' => '',
  'th' => '',
];

The only other option is to introduce a translatable config which users can configure to choose the date format to pass into the date formatter (that way, they can choose to omit S or use a different notation as necessary)

We could try looking into using NumberFormatter for the ordinal, but then we lose the flexibility for users to override the translation to support their specific use case e.g. some clients would prefer to remove the ordinal suffix, or use a custom one instead.

Updated issue to include support for missing ordinal suffix jS.

codebymikey → created an issue.

Also worth checking if this could be consolidated into 📌 Reintroduce Views integration for locale.module Needs work since it makes integration a whole lot easier.

codebymikey → created an issue.

codebymikey → created an issue.

Patch works fine for me.

Provided patches and MR for two approaches.

1. Dropping support for 1.x.
2. Adding support for both versions.

The implementation route is down to discretion of the maintainer.

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

Updated the issue fork so that vocabulary_vid arguments (Taxonomy term: Vocabulary) can be used to override the page title using {{ arguments.vid }}, since it was previously querying the taxonomy_term entity type.

Whilst testing for the #155 issue, I was unable to replicate the bug on a clean install targetting that branch.

I however did run into a separate issue where following the same instructions on a clean 11.x installation, the selected media element is not actually inserted into the page. I'm not sure if a separate media UI issue should be created for it, or addressed as part of this AJAX. But the commit for it is available here if it needs to be moved out.

I was unable to replicate the #168 issue. I've attached a copy of the latest PR, and if you're still having issues, please provide exact instructions on how to replicate on a clean 11.x installation with just the patch applied.

codebymikey → changed the visibility of the branch 2842525-ajax-attached-to-views-exposed-filter-no-variants to hidden.

Drupal appears to cache the contextual links inside the browser's session storage.

So in order to pick it up for existing content, you'll need to manually clear out the session storage so it can be refetched.

Upon upgrading to the latest 3.0.5 version, I was finally able to replicate what my original issue was.

And can be replicated by creating the attached piece of content → on a WordPress installation running Gutenberg 10.7.0 (equivalent of Drupal's v2.14) and WP 5.9, then later viewing the same content after updating to Gutenberg 16.7.0 (equivalent of Drupal's 3.0.5).

The frontend styles and HTML has changed enough that it no longer uses margins for the spacing, however, those same classes are currently missing in the current Drupal implementation and messes up the layout:

The expected layout should be something along the lines of this:

codebymikey → created an issue.

Attached a patch for 10.3.x

codebymikey → changed the visibility of the branch 2842525-ajax-attached-to-views-exposed-filter to active.

codebymikey → changed the visibility of the branch 10.3.x to hidden.

codebymikey → changed the visibility of the branch 2842525-ajax-attached-to-views-exposed-filter to hidden.

The current iteration of the patch triggered the same bug as in 🐛 media_library_opener leads to massive GET requests that break varnish etc. Active for AJAX based media libraries (or any view with pagination by creating an extremely long URL path as it serializes all the POST data as GET parameters).

It ends up picking up all the POST data and using them as the exposed input query string (which is what the pager uses).

I've updated the logic so that it only picks up POST data that have been explicitly configured as being exposed by the handler.

Attached two solutions, one which picks up all exposed inputs which start with the same id → as the exposed filter (because some bespoke filters might have compound fields which have the same prefix, so they might be harder to pick up using the default exposed filter - however this is also a bit of an edge case), and one that should work for about 95% → of all use cases.

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

Removed the needs test tag, and used a more appropriate title.

As per #2, I believe this is expected behaviour, and opting out of it for content moderated content probably isn't advisable, and would cause more issues.

I'd recommend that all development efforts are placed into 🐛 New non translatable field on translatable content throws error Needs work since that addresses the actual issue at hand (stopping it from applying data from non-translatable fields when they're inaccessible).

Depending on how the module works, using this patch can also result in loss of data if the widget returns an empty value when it detects that translations are unsupported as per my smart_date patch (which is probably why Paragraphs are a problem as per @stefvanlooveren - see #3194515-4: Smart Date Recurring doesn't work in non translatable field → )

I've updated the issue summary a bit more to replicate it on a clean install with the 🐛 New non translatable field on translatable content throws error Needs work patch.

As well as attached a copy of a 10.3.2 sqlite database → to demonstate the behaviour. The relevant settings.php setting is as follows after decompressing it:

$databases['default']['default'] = array (
  'database' => '/var/www/html/web/core/default/files/.smart_date-3194515._ht.sqlite',
  'prefix' => '',
  'driver' => 'sqlite',
  'namespace' => 'Drupal\\sqlite\\Driver\\Database\\sqlite',
  'autoload' => 'core/modules/sqlite/src/Driver/Database/sqlite/',
);

And can be triggered by trying to save the translation on /ja/node/1/edit.

The patch in 🐛 New non translatable field on translatable content throws error Needs work helps but doesn't solve this issue because the "original" field value is still being modified when the RRule is initially read in the translation and causes the \Drupal\Core\Entity\Plugin\Validation\Constraint\EntityUntranslatableFieldsConstraintValidator::hasUntranslatableFieldsChanges() call to return TRUE.

Rebased for 11.x, adding support for the 📌 [ignore] Convert everything everywhere all at once Active work.

Version of the patch still using the procedural approach is available here for reference purposes.

It doesn't appear the MR has been merged in.

codebymikey → created an issue.

codebymikey → created an issue.

codebymikey → created an issue.

Attached a static copy of the proposed patch in #22 for those who need it.

codebymikey → created an issue.

The ideas from #27 are interesting enough (especially from an optimization standpoint if you don't want to integrate a reverse proxy for caching purposes).

The https://www.drupal.org/project/page_cache_query_ignore → module seems to address a subset of the functionality without the necessary granularity for controlling the query strings supported for specific routes. The ideas proposed here can be potentially incorporated in that module.

Provide a link to the "Layout Builder Expose All Field Blocks" deprecation issue

Yeah, that's completely fine, feel free to update the issue summary/CR and issue tags as necessary.

@oily, I get your point, I think it just depends whether the XSS filtering is necessary in the first place given how the rendering supposedly works and views being configured by the site builders with admin permissions rather than arbitrary users.

If XSS filtering is not necessary, then removing it solves the actual issue rather than fixing it for this specific video/iframe situation - since the real issue is that the same supposedly "dangerous" HTML elements are rendered on the page when rewrites aren't turned on.

However if the core team determines that filtering is still necessary, then we can make a follow-up issue with direction for how they propose we go about opting out of it. But I think it's worth raising those questions here before this lands.

The more I think back on this, the more I think the current approach wouldn't actually solve the long-term issue (we'll forever be needing to add new elements as necessary to fit the site's use-case).

I think we can keep the API changes to \Drupal\Component\Utility\Xss::filterAdmin() as it's helpful for modules.

But we probably also require a UI option to either:
1. Skip XSS filtering entirely on the specific field rewrite,
2. Allow the user to specify the additional HTML elements which are exempt from XSS for view fields (not sure if this should be a global setting, or on an individual field-level basis).

More thoughts on this are more than welcome.

codebymikey → created an issue.

codebymikey → changed the visibility of the branch 3295745 to hidden.

codebymikey → changed the visibility of the branch feature/3295745-multiple-connectors-5.0.4 to hidden.

The only part I'm not sure I understand is why the div wrapper is needed in the fallback render.

It was necessary because without it, the HTML output was in a different format than if it still had an RRule attached - I think from memory, it'd be just the inner content which makes styling a bit more difficult.

As a potential alternate approach, what about validating the rule object during the initial loop through the $items array?

That'a a good idea, but given the way the rest of the code worked wrt loading the SmartDateRule, I didn't want to move the logic around and potentially break something else or make it harder to review.