@codebymikey

codebymikey → created an issue.

Updated the PR, it includes added support for using passing Markup without it being escaped, as well as passing placeholders as filter parameters.

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

codebymikey → created an issue.

codebymikey → created an issue.

did you QA & Test your new implementation? Does it work properly without introducing any regression to the 8.x-4.x-dev branch?

Yes, and that was why I introduced the tests for Drupal 9.5 so it was easier to confirm the behaviour.

do you really think we should introduce all these new Attributes pattern still keeping the Annotations classes and backword compatibility for Drupal Core versions < 10.2?

I did briefly consider this, but given that Drupal 9.5 was still supported even after the work with ✨ Drupal 10 compatibility: changing php-http/guzzle6-adapter dependency into php-http/guzzle7-adapter RTBC , I thought there might've been a reason (e.g an ideology on the project's side to support as many Drupal versions as necessary), and didn't think it necessitated releasing a major release just for a new plugin discovery method whilst it was still fairly trivial to keep backwards-compatibility.

I think it would be cleaner, but as per the Drupal change record, annotation support is still supported until D12, so it seemed easier to keep compatibility for now whilst giving other contrib/custom modules time to switch to the attribute-based definitions, then when support for

codebymikey → created an issue.

codebymikey → created an issue.

The MR does not appear to be merged in, as it doesn't exist in the latest 8.x-1.x branch.

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

codebymikey → created an issue.

Drupal 8 support is no longer supported, the minimum supported version should be bumped up to >=9 since 8 is already EOL.

See #3094398: Update Symfony response and request events to new classes →

codebymikey → created an issue.

This issue is persist in 4.5.5 but resolved in 4.5.x as 4.5.5 is not a branch it is a tag so I think I won't be able to create a MR that is targeting 4.5.5 let me know if I'm wrong

I don't think it's been fixed in 4.5.x, or at least can't find any commits for it. A patch for it is available here.

The fix will need to be cherry picked onto the 4.6.x branch as well.

The initial /index.php tests failed because the gitlab runner runs under a subdirectory whereas my local environment didn't.

It now takes the $base_path into account when making the test requests.

The test covers a lot more test cases, also opted to use a dedicated service for the stage_file_proxy http client rather than the generic one in case the behaviour needs to be altered for whatever reason e.g. for testing or custom implementation.

@potassiumchloride, do you remember which version you were previously on, as I'm not sure how one of the updates would've broken
the event clicking behaviour, it's always relied on the url property from what I can tell, just like the upstream FullCalendar library does.

I didn't see this in the module docs. If it's not there then this may be helpful to add.

I believe most of the documentation on the upstream library should already suffice for this use case, but the Drupal docs → should be available for you to edit, so feel free to add a section for event URLs/event data structure in there.

In terms of this acting as a drop-in replacement for the FullCalendar View module, my suggested implementation would be using Layout Builder + a simple node page, then using Layout Builder, you can place the Fullcalendar Block within it, and have the block configurations managed that way.

Tokens are also supported (see ✨ Add token support for the event URLs Fixed ), so you can may pass specific arguments contextually into the events if necessary.

This approach provides the most flexibility as it allows you to manage the FullCalendar as you would any other content (e.g. with content moderation whilst providing the ability to easily specify custom URL aliases without necessarily needing to mess around with views configurations).

codebymikey → created an issue.

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.