Instead of having a settings.php entry, how about a submodule, e.g. "Basic Auth with Site Lock" (the name probably needs work) - this would act as the flag instead?
The feature flag module idea is interesting, but seems like potential overhead (haven't benchmarked how expensive calls to the module handler checks are) for a feature that most sites would probably rarely need.
I took inspiration with how the phpinfo() status page behaviour → was changed, and the setting seemed like the way to go for a functionality tightly coupled with the site's security.
However if that's the convention going forward for core to make it easier for non-technical people to work with it, then I have no objection.
Would need input from members on the core team to provide further direction on this.
Added an update that ensures the category loading script behaviour is more consistent.
The nested rendering issue should be addressed by 🐛 Child ordering route renders nested books weirdly Active
The child books will always have at least a single indentation, but didn't want to complicate the logic a bit more than necessary to remove it, but feel free to tweak accordingly if the flat behaviour is desired.
codebymikey → created an issue.
Unsure why 2.0.x MRs are failing, but the failed tests are a separate issue as the tests pass locally.
Can confirm the baseline 2.0.x test failure behaviour with https://git.drupalcode.org/project/book/-/merge_requests/105
Created MR with test cases to showcase the behaviour.
Can't seem to trigger test-only pipelines on 3.0.x, but the test should fail if triggered.
Also fixed an issue with 3.0.x still referencing $node->book rather than $node->getBook(), as I needed it to ensure the tests would pass on the node/{node}/child-ordering route.
codebymikey → created an issue.
The module's already been updated to support Drupal 11.
Thanks for helping out with this!
codebymikey → made their first commit to this issue’s fork.
Thanks for all the work done on this guy!
> The basic auth provider will only act upon routes which have been explicitly tagged with the basic_auth _auth option.
If basic_auth is enabled, and basic auth is received on a route that is *not* tagged for basic auth, should we log or display a warning message?
That's an accidental entry to the issue summary, and actually meant for the 🐛 Basic auth returns 403 when username & password supplied but not needed. Needs work issue.
The changes so far only check for the username's existence.
But no, I don't think it's worth logging it as modules making use of basic_auth should already be tagged as such, and bad actors can use this as a means of filling up the logs without suffering the penalty of being banned by the flood control system.
Added the username check on the basic auth prompt (hidden behind a setting) and a simple test case for it.
codebymikey → changed the visibility of the branch 11.x to hidden.
codebymikey → made their first commit to this issue’s fork.
Updated issue summary with plans to move forward with this.
codebymikey → made their first commit to this issue’s fork.
codebymikey → created an issue.
Attached patch to apply for 2.0.x
The default MR keeps truncation on as part of the post update hook.
Here's a patch that can be applied on top of it that changes the default behaviour to having truncation off by default.
codebymikey → created an issue.
codebymikey → created an issue.
Reopened with a test case triggering the field level violation.
The test-only changes pipeline highlights the issue.
codebymikey → changed the visibility of the branch feature/3295745-multiple-connectors-5.0.22 to hidden.
One thing I forgot to address with this was to ensure the template in final YAML config doesn't have \r\n characters → since that causes the template to be exported as a single line rather than a more human-friendly format. This should probably be addressed in a new issue since it probably affects the rewrite plugin too.
$this->setConfiguration([
static::SETTING_TEMPLATE => str_replace(["\r\n", "\r"], "\n", $form_state->getValue(static::SETTING_TEMPLATE)),
]);
Possible improvement for a follow-up: allow arrays as replacement patterns.
And that's an interesting scenario, this is untested, but that's the beauty of now having Twig available, that scenario should be something users can potentially solve by composing multiple tamper plugins together to achieve the desired effect:
1. Have something similar to the Migrate Plus Transpose plugin to explode then map "name" and "extension" into a single array, then work with it that way (Optional) - On a side note, I think most of the process plugins from the Migrate module are useful inspirations for the Tamper module.
2. Twig plugin: create a multiline string of the items.
{# This assumes names and extensions are always the same length #}
{% set names = name|split('|') %}
{% set extensions = extension|split('|') %}
{% for i, name in names %}
{{ name }}.{{ extensions[i] }}
{% endfor %}
3. Explode plugin: explode items by new line into multiple values per row.
If it's not possible at the moment, then we'd just need to introduce a new plugin that makes it possible to achieve that.
Updated the merge request with the relevant tests highlighted in #6 as well as addressed most of the deprecation and cspell warnings with the exception of the ZfExtensionManagerSfContainer.
codebymikey → made their first commit to this issue’s fork.
Extended the work done by @dkosbob and created an issue fork.
Repurposed this issue for something else as it's a duplicate of an existing issue.
codebymikey → created an issue.
codebymikey → made their first commit to this issue’s fork.
codebymikey → created an issue.
I think having a granular permission makes sense in this case. Mainly for the reason that the administer node permission is typically used in relation to regular node entity operations, and flagging that the user is allowed to make those changes to the node without needing a specific permission for the bundle or field.
My current use case is for a "site admin" role that can essentially do most of the same actions as a regular admin as far as nodes are concerned (apart from rebuilding access), such as view and edit nodes of all bundle types without needing to be explicitly granted permission every time a new one is introduced, the current administer nodes is also currently used for other functionality like views and potentially in other contrib modules, that make use of the permission, so trying to move to the contrib solution probably wouldn't work for me here.
The rebuilding node action seems like a special operation that doesn't necessarily need to be linked to administer node permission, same as the current bypass node access permission.
Provided a new configuration option for specifying HTTP headers that may be specified on the Feed type or individual Feed entity level.
It seems like the latest commit doesn't work for my use case. I've updated the issue summary with steps to replicate the issue.
Unfortunately don't think I'll be able to test and work on this further as I'll be working on migrating to Klaro next, I just thought I'd document this in here because the next version is released.
codebymikey → created an issue.
codebymikey → created an issue.
No thanks, I'll push an issue fork/MR for it in due course.
codebymikey → created an issue.
codebymikey → made their first commit to this issue’s fork.
codebymikey → made their first commit to this issue’s fork.
codebymikey → created an issue.
codebymikey → made their first commit to this issue’s fork.
This appears to be a duplicate of ✨ Update CI configuration Active
codebymikey → created an issue.
codebymikey → created an issue.
Can't delete that bit of code, thats responsible for weeding out any scripts that won't be loaded on the page.
Is that really the case? From my tests and inspecting the code, the $disabled_javascripts entries are weeded out here, in particular: unset($javascript[$script]);, which is what the array_filter() was doing anyway.
I'm working on a solution at the js script end presently to fix it.
That's good to know, hopefully it's something similar to Klaro, where the script tags are replaced with a placeholder one that gets evaluated as a script when the user accepts cookies:
<script type="text/plain"
data-type="text/javascript"
data-eucc-category="analytics"
data-eucc-attach-behavior="customModule"
data-name="custom_module"
data-src="/modules/custom/custom_module/js/custom.js">
</script>
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.