🇨🇦Canada @nedjo

alexpott → credited nedjo → .

phenaproxima → credited nedjo → .

hestenet → credited nedjo → .

nedjo → created an issue.

nedjo → created an issue.

nedjo → created an issue.

nedjo → created an issue.

nedjo → created an issue.

nedjo → created an issue.

nedjo → created an issue.

Related: 🌱 [2.0.x] Roadmap Active .

nedjo → created an issue.

This was done in Configuration Synchronizer by altering this module's Drush command, see #2997360: Add Drush command for the "reset" update mode → .

@pdureau sounds good and makes sense. I'm in any case moving on from Drupal and have already passed on maintainership of Component Schema as well as almost all my other modules. All the best with this initiative.

Flesh out button component example.

Adding headings.

Starting in 2020, I developed the Component Schema module → as a fresh start on the problem set addressed by UI Patterns, UI Patterns Settings and related modules. I did so after working extensively with UI Patterns, UI Patterns Settings, and other similar efforts. I drew a lot on the work done in this module set. I found UI Patterns Settings in particular to be an innovative layer on top of UI Patterns. However, in working with the module set, I kept hitting basic limitations that seemed to me to derive from basic architectural decisions. I decided there was a need to start fresh to meet several key principles.

• Schema-first.
• Typed data built in.
• Inheritance.
• Dedicated classes.

I modelled Component Schema on the configuration schema API from Drupal core, in many cases directly leveraging that API. As a demonstration of how the module works, I coded up a Bulma Components → module that provides a set of components based on the Bulma CSS framework. Using Component Schema, a module or theme may provide a component schema in a .yml file in a component/schema directory, directly parallel to the way modules provide configuration schemas in config/schema .yml files. The Component Schema module itself provides all the basic types that should cover the vast majority of cases. Bulma Components provides a set of reusable types such as bulma_alignment in its own *.yml file. See the Component Schema → documentation for more detail.

I mention this work now because, as a considerable effort is considered towards reworking UI Patterns, there may be an opportunity to leverage the significant work that has already been completed in Component Schema. Specifically, Component Schema could be introduced as a dependency for UI Patterns 2.x, allowing the new branch to take full advantage of the foundational work already complete in Component Schema and freeing up new work to focus explicitly on UI rather than data modelling. As an initial pointer, a sub-module integrating with UI Patterns 1.x, Component Schema UI Patterns, provides pointers on how component schema could provide the data needed for the UI integration in UI Patterns and UI Patterns Settings.

@thejimbirch

Here are some quick pointers that I hope may be enough to get you started.

Config entity types are defined via the ConfigEntityType annotation, see the relevant documentation page → . To list core-provided config entity types, search api.drupal.org for ConfigEntityType and click on the link for the annotation class with the description "Defines a config entity type annotation object." On the resulting page, click to expand "33 classes are annotated with ConfigEntityType" and then click "See full list". Then click on each of the listed types: Action, Block, and so on--though we can presumably skip anything with "Test" in its name.

How do we start to decide which methods should be config actions? Here are some thoughts and suggestions.

For starters, it has to be something that modifies the config entity. Often, that's reflected in a verb that starts the method name. The most common such verb is "set", but there are others.

Once you bring up the class for a config entity type - let's take Block as an example - scroll down to the "Members" section. For "Name does not contain", enter "Test" and for "Type" enter "Function" and click "Filter". In the resulting list, you can ignore any that say "protected" under "Modifiers", and also any function starting with "get" ("getPlugin" and so on), since by definition those methods won't alter anything. Conversely, anything starting with "set" is probably a strong candidate for a config action. For Block, that starts with "Block::setRegion".

https://www.drupal.org/project/usage/features → shows a few hundred installs of either the dev or alpha1 release on the 5.x branch. If further D9 and D10 compatible releases are made on the 3.x branch, those installs presumably won't get update notices but would of course receive notification of a decision to no longer maintain the 5.x branch. It could help to document in advance a plan for how this will work.

Dave Reid and team have stepped up, see #3359810: Seeking new maintainer(s) for Features module in Drupal 9+ → . Thanks! Closing this one out.

@Dave Reid, done, I've assigned you full maintainer permissions. Thanks so much to you and your team for stepping up!

@matthand thanks! I'll let Dave assign you and other co-maintainers as needed.

There may be a place for further co-maintainers, but the main need is now covered and we could consider closing out this issue. A potential remaining question is that of project ownership. If there's interest in considering a change in ownership for Features, that could be pursued either now or at some future date.

@Dave Reid: that's great! Shall I start by adding you as a maintainer, and then you can work from there, adding new co-maintainers as needed?

And, yes, your proposed plan for maintaining the 3.x branch seems sound to me. When I get a chance I'll follow up with more background in #297177: Only tiny bit of image viewing → .

Possibly related: Views Templates → .

But maybe we should add them manually in the meantime.

Like maybe add missing core ones in Twig Template Suggester → ?

Does the equivalent override work directly in the theme--that is, not the skin-specific one? If so, this is presumably one of the core bugs. If not, it might be an issue in Skins.

Thanks @apaderno!

nedjo → created an issue.

Thanks @gisle for making the transfer and @trackleft2, @joegraduate et al for taking on maintenance!

Thanks for noting the issue. Related: #3068461: Make Features UI theme-agnostic → . I wonder if the rules that are breaking in Claro are more leftovers from Seven that now can safely be removed instead of adding exclusions.

nedjo → created an issue.

nedjo → created an issue.

Since per the Accounts section of the Drupal.org terms of service → those using organizational accounts "are not allowed to [. . .] comment on nodes", signoff on behalf of uarizona will be done by joegraduate → (Joe Parsons), who, as can be confirmed on his user account, is Web Architect, Campus Web Services for University of Arizona.

nedjo → created an issue.

nedjo → created an issue.

I confirm (in case opening the issue isn't clear enough ;) ) that I agree to transferring ownership of Configuration Synchronizer, Configuration Normalizer, Configuration Provider, and Config Snapshot from me (nedjo) to uarizona.

These related modules are part of a set of work I've contributed to that provide functionality for Drupal distributions. Developers at uarizona have capably taken on significant maintenance work on the set of modules. As I prepare to move on from work in Drupal, I'm very pleased to be able to leave this work in their hands as well as other current and future co-maintainers of the projects.

Thanks!

nedjo → created an issue.

nedjo → created an issue.

Thanks for reporting the issue. IIRC we modelled the approach here on what was done at the time (early 8.x cycle) in Drupal core for a roughly analogous download--perhaps the download functionality at admin/config/development/configuration/full/export. An initial step would be to see how that code works now in Drupal core. Has it changed in a way that addresses this bug?

Thanks for your work here.

The 2.x branch, however, is not likely to be continued; see #3230397-5: Normalize the way core does → . Instead, a 3.x branch should be created off of the 8.x-1.x branch and D10 updates done there per 📌 Automated Drupal 10 compatibility fixes RTBC .

Per discussions in other issues, work on the 2.x branch is discontinued.

@mark_fuller, okay, I've gone ahead and created a 5.0.0-alpha1 release → and linked to this conversation in the release notes. For now, releases in the 5.0.0 branch is marked supported but not recommended.

Thanks for your notes. While I am currently the most active maintainer in Features for Drupal 9, I am not the project owner. I'm not planning to cut a D10 compatible stable release as I am transitioning out of Drupal and therefore won't be maintaining through the new release cycle. It may be time for some of the steps outlined in the documentation page Finding a new project owner or new maintainers/co-maintainers → .

@valic I created the 2.x branch with the plan of basing it on Bulma Components → , itself based on Component Schema → . However, I'm now winding down my Drupal contributions and won't be completing the work I began there. I would happily pass on both modules to a new maintainer. Failing that, though, the best approach might be to discontinue the 2.x branch and start a new 3.x off of 8.x-1.x.

Tagging with PHP 8.0.

Patch attached.

nedjo → created an issue.

Thx, applied.

Thanks for reporting this issue and submitting a patch.

Confirming that the patch at #15 🐛 Warning: addcslashes() expects parameter 1 to be string, array given in DatabaseConnection->escapeLike() Fixed correctly addresses what is clearly an error in the code. Nice!

More specifically:

• Currently, in i18nviews_translate_page_form(), views_invalidate_cache() is registered as a form submit handler.
• The first argument passed to a form submit callback is a form array.
• However, the first argument to views_invalidate_cache() is an optional cache ID string, with a default value provided. As a result, an invalid value (a form array) is passed in.
• The proposed fix - register a new form submit callback and, from there, call views_invalidate_cache() - correctly addresses this error.

Exactly how does this fix relate to the reported error? That's a bit more involved. Here are the specific steps:

1. When invoked as a form submit callback, views_invalidate_cache() calls cache_clear_all($cid), feeding the form array as $cid.
2. cache_clear_all() loads a database cache object and calls its ::clear() method return _cache_get_object($bin)->clear($cid, $wildcard);
3. ::clear() method calls db_like() as part of generating an argument value: db_delete($this->bin)->condition('cid', db_like($cid) . '%', 'LIKE')->execute();
4. db_like() calls the database connection object's ::escapeLike() method.
5. The ::escapeLike() method calls addslashes(), feeding an array rather than a string, and thus triggers the error.

Nitpick: it would be nice to have a "docblock" for the new form submit callback.

Thanks for reporting the error.

The reported error suggests that, in certain situations, the $field argument passed to field_collection_field_get_path() may be NULL rather than the expected the expected array. The proposed patch in #3 🐛 PHP 7.4, PHP 8.0, PHP 8.1 - array offset on value of type null in field_collection_field_get_path() RTBC looks to handle the case where a field name string (not NULL) might be passed in, and so doesn't appear to address the reported error.

In any case, it looks like any non-array argument value would be an error, so an expected fix would be in the calling code rather than in this function.

From a quick glance, it's not immediately obvious how calling code could end up passing in a NULL value. So before work could be done here, it would be necessary to provide steps to reproduce. Postponing accordingly.

Thanks for noting the error and for contributing the proposed fix.

The error in field_collection_field_update() (an implementation of hook_field_update()) indicates the $top_host variable is, at some point, assigned a NULL value.

The current patch silently accepts a (presumably, invalid?) NULL value for $top_host. That may disguise a problem. It would be preferable to track down and address the source of that NULL value.

There are two points where $top_host is assigned a value. First, it's seeded with the value passed in by the code invoking the hook: $top_host = $host_entity;. Second, it's conditionally reset to the return value of a ::hostEntity() method call:

  while (method_exists($top_host, 'hostEntity')) {
    $top_host = $top_host->hostEntity();
  }

While it's possible the first assignment is the source of this bug - that is, the hook is being invoked with broken data- that seems less likely on the face of it. That leaves the possibility that the ::hostEntity() method method is returning a NULL value. And, indeed, the return value of FieldCollectionItemEntity::hostEntity() is only conditionally an entity, and otherwise NULL.

On that basis, the correct fix here would seem to be to reassign the value of $top_host only if the ::hostEntity() call has returned a non-NULL value.

Patch attached. No interdiff as this does not continue from the prior patch.

Patch per #8 🐛 PHP8.0 Deprecated: Required parameter follows optional parameter Needs review .

A possible interim step would be a soft dependency: use the config_split service, if present, to sort config before it's saved.

Thanks for noting the issue and filing a proposed fix.

Since the $form_state argument is not used in entityreference_autocomplete_process_entityreference(), rather than assigning a default value, it can simply be removed.

-  $title = $title_prefix . $property_info['label'];
+  $title = $title_prefix . (isset($property_info['label']) ? $property_info['label'] : '');

Re this bit, hmm. It looks like it's possible to get back a $property_info array that doesn't have a 'label' key. Is that a valid result? If so, then, yes, this appears to be an appropriate use for the ternary operator.

Since this snippet appears to be constructing a user-facing string, it's not totally clear that the $title_prefix is expected to be valid on its own. This call in entity_views_field_definition() feeds a string that would look odd on its own:

entity_views_field_definition($field . ':' . $nested_key, $nested_property, $table, $title . ' » ');

In that usage, in the case of a missing 'label' key, we might want just the $title without the ' » '. Though whether that's an edge case that's worth addressing at this point....

Thanks for reporting the issue and contributing a proposed fix.

I haven't seen this issue occur, just commenting as part of going through reported PHP 8.1 compatibility issues. I've only taken a brief glance so my comment should be taken as tentative notes made while passing through.

That said...

The issue appears to be in the data returned by entity_get_all_property_info(). The relevant code in entity_views_field_definition() looks to expect a keyed array for the array $property_info argument. So casting as an array whatever data is returned by entity_get_all_property_info() may mask the error without addressing the root cause.

Suggested next step in debugging: determine what non-array values are being returned as part of the entity_get_all_property_info() return value and debug from there, considering the possibilities that the issue may or may not be in this module.

Hope that's helpful!

Of course, the ideal would be that core provided something we could rely on, so we don't need to recreate core's (potentially changing) config sort algorithm in various config modules. That could be, for example, an optional boolean $sort argument to a new ConfigInterfaceInterface::save() method or similar.

Thanks for the report. This appears to result from core changes in [#3230199], see the accompanying change record → . Features needs to sort the way core does. Relevant: #3229250: Add service to sort a config array the same way core does. → . The ideal would be that core exposed a service we could use. Other options seem to include (arranged roughly from most to least attractive):

• See whether this issue is addressed in Configuration Update Manager (which we already require) and, if so, use a service from that module.
• If not already fixed in Configuration Update Manager, or if fixed but not yet available in a service, address in that module.
• Introduce a dependency on Config Split (or some other module that provides a relevant solution). Not so good, as Config Split addresses a distinct set of use cases.

On sites running Pathologic 7.x-3.1, some occurrences of this issue will be resolved by the fix that was committed in #2628348: Language prefix is not split off because of caching → .

nedjo → created an issue.

Thx! Since D8 is no longer maintained, we should remove that.

And let's put this work should in a new branch.

While this is a regression for some sites, it results from changes in 🐛 contextual links for entity view Fixed that benefitted other sites or use cases and at this point is unlikely to be rolled back. Hence marking won't fix.

One option to restore the previous behaviour without patching is to implement hook_block_view_alter() in a custom module:

/**
 * Implements hook_block_view_alter().
 *
 * Conditionally adds contextual links.
 *
 * @see https://www.drupal.org/project/bean/issues/2991960
 */
function mymodule_block_view_alter(&$data, $block) {
  if (!module_exists('contextual')) {
    return;
  }
  $bean = bean_load_delta($block->delta);
  $bean_is_viewable = entity_access('view', 'bean', $bean) && $bean;
  $block_has_content = !empty($data['content']);
  if ($bean_is_viewable && $block_has_content) {
    $data['content']['#contextual_links']['bean'] = [
      'block', [$bean->Identifier(), 'edit']
    ];
  }
}

This also led to the absence of contextual links on some sites, see 🐛 Missing "Edit Block" Contextual Link Closed: won't fix .

When I opened this issue lo these several years ago, my concerns (see the issue summary) were two:

the lack of such classes is [1] a barrier when theming custom blocks and, [2] compared to node, detracts from parallelism between content entity types.

✨ Add block classes for bundle and view mode Closed: duplicate is a good step towards both concerns, so FWIW I agree this can be closed as a duplicate.

@alorenc, thanks! Merged.

3.

+++ b/core/modules/layout_builder/src/Form/BlockVisibilityForm.php
@@ -0,0 +1,358 @@
+              '#type' => 'html_tag',
+              '#tag' => 'b',

This isn't something we should be doing.

3. Not sure what we should do instead.

The comment may refer to use of the b tag, generally discouraged in HTML5 (see for example the article "Using <b> and <i> elements"). strong?

I marked http://drupal.org/node/64984 as a duplicate. There is a patch on that issue.