Is this where we still +1? Ah, good times. Would favor the community-run social media channels ceasing activity (but possibly keeping placeholder accounts) on both Twitter and Facebook and stating the reason why (that these platforms explicitly allowing code of conduct violations, and naming them; being propaganda platforms for reactionary politics and hate i also think are important and related reasons but may be out of our wheelhouse), and pointing to fediverse and other accounts.
A fairly simple example, tested and working.
ECA could definitely do this, it would be a completely separate capability from ECA Access (which uses hook_node_access), so i withdraw/redirect the initial request; Drupal basically has two different systems, and i think ECA could plug into this one as well. Maybe an eca_node_access module.
/**
* @file Access hooks for advocates.
*/
use Drupal\Core\Session\AccountInterface;
use Drupal\node\NodeInterface;
/**
* Implements hook_node_grants().
*/
function hw_advocate_node_grants(AccountInterface $account, $operations) {
$grants = [];
if ($account->hasPermission('advocate for clients')) {
$household_nodes = \Drupal::entityTypeManager()->getStorage('node')->loadByProperties(
[
'type' => 'household',
'field_advocate' => $account->id(),
]
);
foreach ($household_nodes as $node) {
$grants['hw_advocate'][] = $node->id();
}
}
return $grants;
}
/**
* Implements hook_node_access_records().
*/
function hw_advocate_node_access_records(NodeInterface $node) {
$grants = [];
if ($node->bundle() === 'household') {
$grants[] = [
'realm' => 'hw_advocate',
'gid' => $node->id(),
'grant_view' => 1, // TRUE, but docs say 1
'grant_update' => 1,
'grant_delete' => 0,
];
}
return $grants;
}
I had been thinking of doing this in https://api.drupal.org/api/drupal/core%21modules%21node%21node.module/fu...
But the recommended/correct way for intervening for content access that works for queries is via giving grants to users and defining the
https://api.drupal.org/api/drupal/core%21modules%21node%21node.api.php/f...
https://api.drupal.org/api/drupal/core%21modules%21node%21node.api.php/f...
And on further consideration those hooks are what we would want to make available to ECA.
Committed fix to dev release branch.
mlncn → created an issue.
Include steps to get to be able to select field to override.
(anything based on this approach would generally be sub-optimal performance-wise, like a giant IN
statement rather than a beautifully crafted set of joins, but it should still work…)
mlncn → created an issue.
Thank you jurgenhaas! Sorry yes that is what i was first trying to ask so ineptly, what is the mechanism for making a renamed copy of an entity. Token: set value it is! (I know that must seem like the most basic building block of ECA to you, but i've always encountered the naming capability within actions with additional purposes.
Now at the end of the chain, how do i make it apply to the correct entity? (10 minutes later, after fixing the token set value by including the brackets around entity, realizing what i'd initially hoped and what you repeatedly said) Now that i have been able to pipe the household entity coming out of the Access Event into the chain by renaming it to household, the same as it is called when loaded from the individual entity access event, there is only ever one event happening at a time so the existing "Set access result" works just fine.
The "hacky workaround" i'd hoped for is the correct and proper way!
Thank you!!!
At long last, this documentation page is added!
https://www.drupal.org/docs/extending-drupal/contributed-modules/entity-... →
(Because i can never find it, here's the documentation on adding documentation guides, which, other than adding a link to it, is completely separate from the project page: https://www.drupal.org/drupalorg/docs/content/documentation#contrib → .)
Cannot reproduce in Drupal 10 / PHP 8 (which is the minimum now → )
Agreed @borisson_ — and turns out this patch was the same as the bot attached to the Drupal 11 compatibility issue.
This annotation probably is more useful in describing the disconnect than the whole recipe though— models can have multiple events, that can flow into the same chain of logic, which is why we want the ability to match access event to set access result, to be able to specify that context in the model.
It's got a lot of content types, sorry, but a recipe of the ECA workflow may help here.
Code looks great, and this is very needed!
Added "entity_reference_override_entity_browser" as a component so we can track follow-up issues for this submodule there.
Amazing work all! Bringing this in; maybe we label it "experimental" if we go for a full release of the main module before a lot more community testing, but as a sub-module it should not affect the stability of the main module.
Leaving active for the bot to come along and make more suggestions.
Yes, will commit, would like a bit more review and a couple more bug-fixes before a stable; 🌱 Roadmap to a stable release Active could be updated or closed in favor of a newer issue to track this.
Minor code formatting issue but can take care of that while resolving the 'merge conflict' with another schema omission fix that was already brought in.
No reason not; looks good!
We did get that test; including this submodule in the dev release and we can work on moving re-usable code to traits from there.
Well we are in beta and seem to be surviving without a more complete fix to this issue, maybe we go officially stable with this edge case too.
Ah great, and such a simple fix.
Ah in fact milkovsky incorporated this fix four years ago in Issue #3109470: Warning: Illegal string offset 'value' on save → ; well let's finally give credit in this issue.
Looks good, thank you.
@rp7 are you still actively using the module? Interested in being a co-maintainer?
Oh classic. Thank you for the fix f2boot hope your patch has been working well for you and others these long years of not getting brought into the module… remedying that shortly.
@amaisano Do you have custom code or patch files still lying around with the fix possibly? Agreed the listing of fields that can be overwritten is missing the text fields it should list, and fixing that would be a major improvement.
Thank you!
Declaration of D11 compatibility made, back to active for any future contributions of the bot.
Probably any more rector issues would come in 📌 Automated Drupal 11 compatibility fixes for customerror Needs review
We'll probably remove this functionality instead of fixing it if no one has a fix forthcoming.
Are there any modules that allow changing the theme on a given path that we could document as the recommended way to do this?
GitLab could not be more annoying today. Brought in. (TIL: Using .diff instead of .patch on the merge request can work better when there have been changes.)
@tarik thank you for the work and apologies for the two-years-late review. There were a lot of code style changes and improvements that will have to be handled separately from this change.
The decision taken in the code is to hard-code the format to full_html
which is defensible, but i don't think we can be guaranteed to have that format. Also existing messages need to remain as the default 'no-format' raw HTML.
Ah, OK, the goal is to be able to disable redirection to not take the performance hit of checking for where somebody came from in their session.
As Leo's comment in the code put it: Recording sessions for different anonymous users prevents caching from working optimally
Fine to have an option, could you update the code to use the injected $this->configFactory
rather than \Drupal::config
and, most important, have this checkbox be set to enabled for existing sites (adding it to the schema and i think an update hook needed to set it as well).
Thank you for your contribution!
(the merge request refused to merge due to test failures unrelated to the changes here, so patched local code and pushed)
Definitely looks like an improvement/fix for the current code; still feels like we should find a way to not have to do this at all but that would be a major refactor of the module probably with less functionality, to have our message at the not found URL rather than at our own path. Merge request approved.
This issue for Revision Log Default module, if implemented, would be a workaround: ✨ I want independent displays of published / unpublished status and moderation status Active
As a first step for this issue, instead of "Updated the Published field" we should say "Published" or "Unpublished"
Echoing this request, which seems to be a feature need— the promise "Revisions allow you to track differences between multiple versions of your content, and revert to older versions" and to then "Compare selected revisions" definitely leads one to expect that a major difference such as published versus unpublished would be shown.
Maybe the real feature need is adding all core pseudo-fields— promoted, sticky, etc as well as published?
Congratualations on figuring #3489493 out and apologies for not helping there; but this should be unblocked now.
Thank you Dileep, and Shashi for the review!
This appears to be an obvious if uncredited modern Drupal port of the Drupal 7 Security Questions module: https://www.drupal.org/project/security_questions_d8 →
This is very silly, but made a helper module to do this: Taxonomy Machine Name Helper →
Now my code (note as before it loops through fields, which is a little unusual for this but doesn't change how this helper function is used really) looks like this:
if ($field === 'field_search_zip' || $field === 'field_search_radius') {
taxonomy_machine_name_helper_set_dependent_field_state($form, 'field_search_by', 'zip_code', 'search_by', $field);
}
elseif ($field === 'field_address_county') {
taxonomy_machine_name_helper_set_dependent_field_state($form, 'field_search_by', 'county', 'search_by', $field);
}
The signature of the function being used there is:
/**
* Set form field state based on term machine name in controlling field.
*
* @param array $form
* Form to make the changes to.
* @param string $controlling_field
* Machine name for the controlling field (must have options that are taxonomy terms).
* @param string $term_machine_name
* Term machine name that triggers target field behavior (must be provided by Taxonomy Machine Name module).
* @param string $target_field
* Machine name for the target field.
* @param string $state
* Optional state to put the target field in when the term matching the term machine name is selected. Defaults to 'visible'.
*/
function taxonomy_machine_name_helper_set_dependent_field_state(&$form, $controlling_field, $term_machine_name, $vocabulary, $target_field, $state = 'visible')
It also checks that it can load a term of the given machine name, and logs a warning rather than blowing anything up if it cannot, and abstracting that code for re-use is really what tipped me into making it a contribution.
I made a separate module because i didn't really see this being accepted as a feature request but would happily roll it into taxonomy_machine_name itself if it is welcome.
mlncn → created an issue.
It is not hard to use the provided taxonomy_machine_name_term_load() function to do this; but the module page documentation should add the modern Drupal section (the function name has been corrected since D7).
foreach ($search_fields as $key => $field) {
$zip_term = taxonomy_machine_name_term_load('zip_code', 'search_by');
if ($field === 'field_search_zip' || $field === 'field_search_radius') {
$form[$field]['#states'] = [
'visible' => [
':input[name="field_search_by"]' => ['value' => $zip_term->id()],
],
];
}
$county_term = taxonomy_machine_name_term_load('county', 'search_by');
if ($field === 'field_address_county') {
$form[$field]['#states'] = [
'visible' => [
':input[name="field_search_by"]' => ['value' => $county_term->id()],
],
];
}
}
(this is looping
Tested, this is working fine, and looks like the least amount of code to get the job done. Nice!
Should probably link to Taxonomy Machine Name from this module's homepage.
mlncn → created an issue.
mlncn → created an issue.
Extremely straightforward and fixes a major problem. Agreed on the RTBC.
In our case, latest Drupal 10, the "file" blamed where there is no "function" is "/var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php" and its all the way in $backtrace[2] that the first function is, "handleRaw" for class "Symfony\Component\HttpKernel\HttpKernel" in file "/var/www/html/vendor/symfony/http-kernel/HttpKernel.php". No clue what the original error would be that would get us in Error.php in the first place, it's Drupal's own middleware all the way down to DrupalKernal/index.php, but presumably a proper fix to this would help surface the underlying cause of the warning?
mlncn → created an issue.
This is good to go!
Perhaps this could be done with an inbound path processor?
mlncn → created an issue.
Wow, thank you! I guess i forgot to implement this more straightforward option entirely.
Merged this in, hope more people can review the branch and will make a release soon.
Uh, in case i forget, @jacobupal are you interested in being a co-maintainer?
Thanks!
mlncn → created an issue.
mlncn → created an issue.
Have this for two columns now! (which is all we have so far, #3480393 )
mlncn → created an issue.
mlncn → created an issue. See original summary → .
mlncn → created an issue.
With PHP 8.3.12 i am getting:
Error: Undefined constant "MENU_CALLBACK" in /var/www/html/web/modules/contrib/drupalmoduleupgrader/src/Routing/HookMenu.php(73) : eval()'d code on line 24 #0 [internal function]: ark_menu()
#1 /var/www/html/web/modules/contrib/drupalmoduleupgrader/src/Routing/HookMenu.php(87): call_user_func()
#2 /var/www/html/web/modules/contrib/drupalmoduleupgrader/src/Plugin/DMU/Converter/Routing.php(70): Drupal\drupalmoduleupgrader\Routing\HookMenu->getSourceRoutes()
#3 /var/www/html/web/modules/contrib/drupalmoduleupgrader/src/Commands/DrupalmoduleupgraderCommands.php(188): Drupal\drupalmoduleupgrader\Plugin\DMU\Converter\Routing->convert()
#4 [internal function]: Drupal\drupalmoduleupgrader\Commands\DrupalmoduleupgraderCommands->upgrade()
#5 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(276): call_user_func_array()
#6 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback()
#7 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(175): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter()
#8 /var/www/html/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(387): Consolidation\AnnotatedCommand\CommandProcessor->process()
#9 /var/www/html/vendor/symfony/console/Command/Command.php(326): Consolidation\AnnotatedCommand\AnnotatedCommand->execute()
#10 /var/www/html/vendor/symfony/console/Application.php(1096): Symfony\Component\Console\Command\Command->run()
#11 /var/www/html/vendor/symfony/console/Application.php(324): Symfony\Component\Console\Application->doRunCommand()
#12 /var/www/html/vendor/symfony/console/Application.php(175): Symfony\Component\Console\Application->doRun()
#13 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(110): Symfony\Component\Console\Application->run()
#14 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(40): Drush\Runtime\Runtime->doRun()
#15 /var/www/html/vendor/drush/drush/drush.php(139): Drush\Runtime\Runtime->run()
#16 /var/www/html/vendor/drush/drush/drush(4): require('...')
#17 /var/www/html/vendor/bin/drush(119): include('...')
(And i still get the same error if i throw define('MENU_CALLBACK', 0x0);
into the module i'm trying to upgrade.)
Are they visible to Search API?
Looks good, thank you!
Hmm, actually we do need a bit more of an API than #gin_action_item
or the code needs to be changed to allow an explicit ['#gin_action_item'] = FALSE
to override Gin's hardcoded $include (used in includes/form.theme
around line 90).
Currently there is no way to move, say, the Save button into the Kebab when, say, the "Save and Edit Layout" should be primary.
The merge request in 🐛 Cannot opt out buttons using #gin_action_item = TRUE Active restores an ability for third-party code to place buttons to the emphasized area outside of the kebab menu by adding in a form alter hook:
$form['actions']['example_button']['#gin_action_item'] = TRUE;
So as things stand the resolution to this issue is for that issue to be committed and closed as fixed and then for us to document it somewhere here –
https://www.drupal.org/docs/contributed-themes/gin-admin-theme →
– and i think in gin.api.php
also.