mlncn → changed the visibility of the branch 3516112-upgrade-to-drupal to active.
mlncn → changed the visibility of the branch 3516112-upgrade-to-drupal to hidden.
This is fantastic. I'll have to test it out later if nobody else gets to that first but the code and tests look great!
We are technically still in beta but we could do a 2.0.x release (side benefit: gets us in modern versioning numbers, away from 8.x-1.x) to avoid people running into form ID troubles without a little warning.
Removed the use statement in favor of \Exception because non-namespaced classes/interfaces/traits should not be referenced with use statements.
This is definitely fixed, feel like it could be done better? More specific exception maybe?
well i cannot find a way to check that there is a route before doing the match request (there probably is though?) but wrapping the attempt in an exception handler works fine. Maybe it would be better to target the specific exception if going this route (no pun intended), but this fixes the fatal error.
> $fields = \Drupal::service('value_revisions.settings')->fieldsInfo($entity);
= [
"title" => [
"field_type" => "string",
"widget_type" => "string_textfield",
],
"field_addresses" => [
"field_type" => "entity_reference",
"widget_type" => "inline_entity_form_complex",
],
"field_aka" => [
"field_type" => "string",
"widget_type" => "string_textfield",
],
"field_alternate_names" => [
"field_type" => "string",
"widget_type" => "string_textfield",
],
"field_email_addresses" => [
"field_type" => "email",
"widget_type" => "email_default",
],
"field_industries" => [
"field_type" => "list_string",
"widget_type" => "options_buttons",
],
"field_naics_codes" => [
"field_type" => "string",
"widget_type" => "string_textfield",
],
"field_phone_numbers" => [
"field_type" => "telephone",
"widget_type" => "telephone_default",
],
"field_related_actors" => [
"field_type" => "entity_reference",
"widget_type" => "entity_reference_autocomplete",
],
"field_tags" => [
"field_type" => "entity_reference",
"widget_type" => "",
],
"field_visas" => [
"field_type" => "entity_reference",
"widget_type" => "entity_reference_autocomplete",
],
"field_websites" => [
"field_type" => "link",
"widget_type" => "link_default",
],
]
When a widget is blank, as in this example for tags, that is because at some point after configuring Value Revisions for the field, the decision was made not to show the field on the form.
mlncn → created an issue.
mlncn → created an issue.
mlncn → created an issue.
And the module is done!
Administration Theme by Content Type - https://www.drupal.org/project/admin_theme_by_content_type →
I think you are right it is more straightforward for the end-user as a standalone. Thanks!
Thank you so much for your quick and kind response!
Admin Theme has the same
I am curious why Simple Admin Theme by Route uses event subscriber when alterRoutes should be enough to add _admin_route
And do you know for certain that your EventSubscriberInterface onKernelRequest() cannot set the theme for non-route things like path for the creation forms and what type of object (or rather bundle of entity) for edit forms? Since i'll have to grab the request anyway your approach seems a little more straightforward than the ThemeNegotiator approaches i'm finding.
Thank you very much for everything!
(New module coming shortly…)
In our case it was to adjust column heights in order to see the text properly (display issue probably specific to LibreOffice Calc) and also in our case to quickly confirm that the hidden Key column was using an export-specific ID (which we sort of knew it had to be, but somehow this seemed the fastest way to check).
Above commit appears to work perfectly (for the narrow and i think our only current use case of addresses); i just had thought i'd made the revision an official source when i had not. If we have any other inline entity references it should be pretty easy to expand that approach.
Well, with one more caveat— we are checking only one field on the address entity, field_address. (That one field happens to have like 14 parts, of which we currently check about half for the value hash, but it could be made all easily.) The present client actually adds another field, for the type of address (mailing, physical etc). I am willfully ignoring that in the value hash as not important enough to affect which revision the address is attributed to. But most inline entities will probably be made up of several relevant fields which would entail a different, and certainly more annoying, strategy for calculating value hashes.
See 🌱 Offer to co-maintain / issue fork for updated version Active issue fork.
See 🌱 Offer to co-maintain / issue fork for updated version Active issue fork.
See 🌱 Offer to co-maintain / issue fork for updated version Active issue fork.
Add link from FAQ to main documentation on same topic.
mlncn → created an issue.
mlncn → created an issue.
Actually the best solution would be to use https://www.drupal.org/project/entity_reference_revisions → and then we would be saving the revision ID instead of the entity ID.
So long as that is smart enough not to change the revision ID if nothing changes (doubtful?)
And provided it works with Address module.
mlncn → created an issue.
The code to make it work was partially there. The merge request finishes and fixes that work.
Also wanted to note that ECA module → could be configured to do this and it has true entity validation now ✨ eca_content: Provide plugins for entity validation Fixed
… and true entity validation, not form-level validation, is what i wanted and expected from Unique Field but that is not what Unique Field does. That should also be documented clearly or fixed, but i hope my contribution here is useful but i'm going to switch to ECA.
Still not working and this is arguably half of the documented functionality, not working, so i would call this major at least until the module page and internal documentation is updated to note this functionality is aspirational and not in fact implemented in current versions.
… fixed after a cache reload!
mlncn → created an issue.
Looks good (i've looked at a lot of these lol) and works, thank you! As noted already in the issue summary there are no compatibility concerns given Drupal core's minimum PHP requirements.
Major, because a priority major is postponed for this currently. (This and 📌 Support OOP hooks Active (or combining them into one issue again) are needed for Field Encrypt to work on Drupal 11.1.)
Definitely do think the hooks should be in separate files based on usage, loading only what is needed when it is needed is a big benefit of OOP hooks, but that can be a later code reorganization.
So it is not a Drupal Core issue (as i guess i should have expected)— it occurs due to the Drupal 11.1-compatible issue fork of Field Encrypt 📌 Support OOP hooks Active , specifically the src/FieldEncryptServiceProvider.php file, which is… not mentioned in the field_encrypt.services.yml Huh, did not realize there would be anywhere Drupal automatically interprets something not in Plugins or something like that. Anyhow if there is anything that jumps out to core maintainers for Field Encrypt to fix… 📌 Support OOP hooks Active
New merge request against the correct branch.
mlncn → changed the visibility of the branch 3511754-deprecated-implict-nullable to hidden.
mlncn → changed the visibility of the branch 3511754-update-deprecated-implicitly to hidden.
Dammit that was against 8.x-1.x and just silently made the 2.0.x changes? I never made the changes dropping 8/9! Anyway if a maintainer could make 2.0.x branch the default i'm sure that'll make contributions easier going forward.
@sergio morais are you using this module? Would you want to co-maintain?
Awesome thank you! Better than what i had locally because i had not internalized the `?` shortcut yet (seemed FormStateInterface|null but the shorter form is nicer especially with that longer form already in the docblock code comment.
mlncn → created an issue.
Excellent. A release would be a good idea still!
Preventing WSOD's by catching an exception here has become increasingly important with something that changed in Drupal 11.1 or in PHP 8.4. Something that did not used to be a noticeable warning on the status page is now a fatal error on the status page with a "White Screen Of Death", and a stack trace that starts with:
"Drupal\Component\Utility\Html::escape(): Argument #1 () must be of type string, null given, called in /var/www/html/web/core/lib/Drupal/Component/Render/FormattableMarkup.php on line 238"
And then leads the perplexed site maintainer or developer on a journey through TranslatableMarkup and Twig\Template->display() and twig_template_render and Drupal\Core\Render\Renderer->doRender among other less notable stops, with the template and rendering stuff all showing up twice. But not once does the stacktrace give a hint of what code actually started the problem.
Using a debugger one can go a few steps down (up?) the stack to Drupal\Core\StringTranslation\TranslatableMarkup and find the variables passed into it. These made clear that the underlying problem is that a custom profile has no version string. (OK, and looking at this, separate issue from this one, probably status_report_grouped should be taking care not to require information that is not required?)
(OK i must have been wrong about their being no error, i see escape() used to have this code: @trigger_error('Passing NULL to ' . __METHOD__ . ' is deprecated in drupal:9.5.0 and will trigger a PHP error from drupal:11.0.0. Pass a string instead. See https://www.drupal.org/node/3318826', E_USER_DEPRECATED);. But that does not change the fact that Drupal has increased the ways a fatal error can take down a site in ways that can have many sources and be hard to track down.)
Strict typing is great for coding. But there are too many ways a non-string can end up handed to HTML::escape() to take down a site over it.
Works great on the 4.x branch! No deprecation warnings, and Field Group still works.
(People who contributed partial fixes to issues closed as duplicates who should get credit when this is fixed include prem suthar, deepali sardana, MrDaleSmith, and nickdickinsonwilde. And solideogloria who is already over here!)
It is quite bizarre because the errors are for not finding the database connection, but elsewhere in Drupal, outside the DatabaseLockBackend, it certainly has no trouble accessing the database. I can even get it to run the updates simply by putting an if ($this->database) { check in there; the pre-existing code to go back for another try works fine it seems, but the exception i am getting is not one that was expected.
The same sort of error (query on NULL database) happens in this block, but running the database updates a second time works; clearly it is able to get the database sometimes.
try {
$lock = $this->database->query('SELECT [expire], [value] FROM {semaphore} WHERE [name] = :name', [':name' => $name])->fetchAssoc();
}
catch (\Exception $e) {
$this->catchException($e);
// If the table does not exist yet then the lock may be available.
$lock = FALSE;
}
mlncn → created an issue.
Stripped down, MySQL only, no tests, try at an updated patch. Sorry will try to do more. Though i do think the adding the upsert multivalue capability and using elsewhere in Drupal can and should be separated issues.
There is no "2.x" branch ( that i can find → , anyway). There are 2.0.0-beta1 and 2.0.0-beta2 tags, but they were both tagged from the 8.x-1.x-dev branch. (Notably, the 2024 April 9 2.0.0-beta2 → release supports Drupal 10.
The bot did not create a D11 issue; i don't think there's anything wrong with us doing it all here.
We should be all set for Drupal 10 (as noted, already released) and 11 here in MR 4.
Seems first commits do not trigger cross-referencing with issues: 523ed61e6a719f85bdb76dd761cab2432a9e6bc0
Well, using the issue fork from 📌 Remove uniqid field from serial storage table RTBC
And it is still a complete disaster. No serial IDs created retroactively. Only doing this on one content type for now.
MariaDB [db]> SELECT * FROM serial_0420c62dd723430557835bf4ac5a5493;
Empty set (0.000 sec)
MariaDB [db]> SELECT * FROM node__field_serial;
Empty set (0.000 sec)
After editing one piece of content:
MariaDB [db]> SELECT * FROM node__field_serial;
+------------+---------+-----------+-------------+----------+-------+--------------------+
| bundle | deleted | entity_id | revision_id | langcode | delta | field_serial_value |
+------------+---------+-----------+-------------+----------+-------+--------------------+
| individual | 0 | 693010 | 1464063 | und | 0 | 1 |
+------------+---------+-----------+-------------+----------+-------+--------------------+
1 row in set (0.000 sec)
MariaDB [db]> SELECT * FROM serial_0420c62dd723430557835bf4ac5a5493;
Empty set (0.001 sec)
And then after creating one piece of content:
MariaDB [db]> SELECT * FROM node__field_serial;
+------------+---------+-----------+-------------+----------+-------+--------------------+
| bundle | deleted | entity_id | revision_id | langcode | delta | field_serial_value |
+------------+---------+-----------+-------------+----------+-------+--------------------+
| individual | 0 | 693010 | 1464063 | und | 0 | 1 |
| individual | 0 | 748330 | 1464064 | en | 0 | 1 |
+------------+---------+-----------+-------------+----------+-------+--------------------+
2 rows in set (0.000 sec)
MariaDB [db]> SELECT * FROM serial_0420c62dd723430557835bf4ac5a5493;
+-----+
| sid |
+-----+
| 1 |
+-----+
1 row in set (0.000 sec)
Believe we may also be seeing this.
And to be clear i only have return grants statements in my code, nothing that should do this on its own.
mlncn → created an issue.
17 | ERROR | [ ] Parameter $account is not described in comment
| | (Drupal.Commenting.FunctionComment.ParamMissingDefinition)
20 | ERROR | [ ] Doc comment for parameter $account; does not match actual
| | variable name $account
| | (Drupal.Commenting.FunctionComment.ParamNameNoMatch)
/**
* Triggers gathering grants.
*
* @param \Drupal\Core\Session\AccountInterface $account;
* The user account.
*/
public function grants(AccountInterface $account) {
Is PHPCS drunk?
mlncn → created an issue.
Possibly related to 🐛 Visibility groups don't remove existing visibility rules Active
Reminder to try to figure out how other modules prevent this unneeded config.
mlncn → created an issue.
Also using it, on into Drupal 11. Tested and approved.
Included filepaths of examples. Also started moving naming convention of examples toward 'example' and away from 'test'.
Active branch does everything… except token replacement for the actions! Something obvious i am sure but way out of time to work on this for a while.
Finally back to this, and i don't think ECA Content Access is what i am looking for.
First, there should not be a need for the Content Access contrib module.
Second, and most important, it lets the access for a role to be changed from the configured Content Access default for an individual node, but it does not allow varying the access per user account.
Third, to do things in the way node access works best, we really should be able to set grants on the account and grants on a node. Content access is using node_grants but not exposing the full flexibility. (Also, though i don't know if it matters, it is not defining a realm at all.)
Here is the underlying method eca_content_access uses, from NodeAccessControlHandler:
* @param \Drupal\node\NodeInterface $node
* The node whose grants are being written.
* @param array $grants
* A list of grants to write. Each grant is an array that must contain the
* following keys: realm, gid, grant_view, grant_update, grant_delete.
* The realm is specified by a particular module; the gid is as well, and
* is a module-defined id to define grant privileges. each grant_* field
* is a boolean value.
* @param string $realm
* (optional) If provided, read/write grants for that realm only. Defaults
* to NULL.
* @param bool $delete
* (optional) If false, does not delete records. This is only for
* optimization purposes, and assumes the caller has already performed a
* mass delete of some form. Defaults to TRUE.
*/
public function write(NodeInterface $node, array $grants, $realm = NULL, $delete = TRUE);
Used here:
if ($this->updateSettings($bundleSettings, $this->configuration['operation'], $this->configuration['role'])) {
$this->database->merge('content_access')
->keys(['nid'], [$entity->id()])
->fields(['settings' => json_encode($bundleSettings)])
->execute();
/**
* @var \Drupal\node\NodeAccessControlHandler $controllHandler
*/
$controllHandler = $this->entityTypeManager->getAccessControlHandler('node');
// Apply new settings.
$grants = $controllHandler->acquireGrants($entity);
$this->grantStorage->write($entity, $grants);
@TODO offer same patch to IEF
@vinayakmk47 This is fixed in the @dev version. Fixed in issue 📌 require drupal/inline_entity_form ^1 || ^3 Fixed
Please try that out (composer require 'drupal/ief_complex_open:1.0.x-dev@dev') and if it works we'll make a stable release.
Thanks!
@darkdim rather than having the overhead (and harder-to-follow code) of actually implementing the the event handler, is it OK to treat it as an "alter" event and only have an example of implementing it, perhaps in a registration_role.api.php file?
Thanks so much, i do think we should bring this in before we change anything that would break applying this merge request as a patch.
Current code in: https://git.drupalcode.org/project/registration_role/-/merge_requests/3/...
Also is the gitlab-ci.yml something all contrib projects should have now?
Release made! Sorry for the delay.
https://www.drupal.org/project/registration_role/releases/2.0.2 →
Will leave my custom code here for now:
/**
* Implements hook_form_BASE_FORM_ID_alter() for taxonomy term add/edit forms.
*
* Thanks to https://www.bryanbraun.com/2013/08/17/using-hook-form-base-form-id-alter/
*
* Really wonder if there is a bundle class way to get at these forms.
*/
function massdesigngroup_form_taxonomy_term_form_alter(&$form, FormStateInterface $form_state, $form_id) {
// If we have an organization term, restrict Rabbit Hole options to default or display.
$vocab = $form['vid']['#value'] ?? '';
if ($vocab === 'organizations' && isset($form['rabbit_hole__settings']['widget'][0]['action']['#options'])) {
unset($form['rabbit_hole__settings']['widget'][0]['action']['#options']['page_not_found']);
unset($form['rabbit_hole__settings']['widget'][0]['action']['#options']['page_redirect']);
// Access Denied is an option we want, but only as the global behaviors default.
unset($form['rabbit_hole__settings']['widget'][0]['action']['#options']['access_denied']);
}
}
Working, and the code is a straightforward minimal validity check.