🇳🇿New Zealand @John Pitcairn

If the image field is in fact a media entity reference, that's probably the contextual module giving you an edit menu for the referenced media entity. Not for the image field itself.

Text fields are not entity references, therefore no contextual edit menu. You have to edit the node entity.

CCK has been part of Drupal core since Drupal 7.

Relationships from one entity to another are handled by the core entity reference field. You use that to build your relationships. There are also contrib modules that extend what core entity reference can do.

Custom database queries can be built and displayed entirely using the UI by the core views module.

You generally don't want or need to be thinking much about the actual database storage unless/until you are doing something unusual, but relational DB thinking maps very well to using entity references.

Might we consider also introducing the use of @layer to help tame some of ridiculous specificity that both Sass and native nesting cause?

+1 to #27. Removing them outright would be disastrous.

I use (or abuse) those fields on some sites, though I usually change their labels to reflect the specific outcome for each site.

1. Users who have requested a password reset should not be redirected to a dashboard before they are able to set a new password.
2. If another login redirect is present, eg from Login Redirect module, or configured via an ECA rule, dashboard should not override that.

Item 2 could possibly be met by a simple enable/disable checkbox. Item 1 cannot.

My recommendation would be that if redirection is desired, starshot should use a dedicated configurable login redirect module or ECA rule. We should not rely on a simplistic solution here, it will only wind up needing special case logic that is already solved in contrib. Redirect should be out of scope for this module.

I quite like #5.

That has the potential to be more flexible for site builders without baking in any assumptions that there are only the 2 options.

#7: There is an issue or two somewhere that touches on current problems with that.

I wanted to extract the display config to preset and hide field formatter complexity for layout builder inline field blocks, but LB disables manage display, and if using config from a different view mode as a workaround, any disabled fields in manage display do not retain their display config (something like that).

I'll see if I can find the issue(s).

Whatever solution is chosen should allow site builders to flag any field as a meta field, whether that's a core field, contrib field, or field they have added in the UI. We shouldn't make any assumptions about existing fields or field types.

• A site builder may add a core media reference field that will never be displayed in the layout, but is used to set the canonical entity display og:image header meta element for social media previews. That shouldn't appear as a layout component, it's definitely a meta field from an author's point of view.
• A site builder may add a contrib location field that will not be used to display a map, but will be used to contextually filter other content available on the entity display via views block components which were placed by XB (ie you don't want to have to specify the location in every one of those components).

My preference would be option 1 or 2: an additional setting exposed in the UI for each field instance form, or for each form display widget setting. Option 1 might be better for supporting decoupled edit forms, not sure.

I don't like option 3. This is generically very useful and shouldn't be tied to XB – admin themes could use it to move those elements into their entity form meta group, instead of hard-coding "known" meta fields in a form_alter() and requiring a site dev to move any others via the same fragile mechanism.

That's not the point. There are many ways to create login redirects. This module shouldn't blindly override those, especially if it's from a password reset.

John Pitcairn → created an issue.

John Pitcairn → created an issue.

Note hook_module_implements_alter() will not work if you need your hook_preprocess_HOOK() to run after some other module's preprocess hook. Preprocess hooks are not invoked by the module handler and are not present in hook_module_implements_alter().

So removing this API will be problematic if you have a soft dependency on another module's preprocess hook, ie the module is not a requirement, but if it is present you need to preprocess something it also preprocesses, after it has done so. You don't want to declare a hard dependency in module .info. Altering module weight is the only way this will work, right?

+1 to the above. Useful in update hooks where you're fixing bad data, updating data formats, etc. Setting isSyncing before save when doing so just seems like an abuse of the flag for that purpose.

OK fair enough. Update drafts only.

I guess we can run our own update to fix past completed/failed orders after all orders in needs_payment at initial update time have either completed or failed. So we have consistent data.

Sure. Was just wondering about keeping it as is and adding a calculated subscription_period field, using that for display, email etc. So the current assumptions and data would not change.

Can't help but thinking we have a naming problem here, ie we call it the "billing period", but it's always used as if it were post-paid – so it is not the same as the subscription period for pre-paid subscriptions.

This makes me very nervous, and not just about the possibility of skipping a cycle. All our orders are prepaid.

If we only update draft order billing periods, pushing them out by 1 cycle, then we will have a "missing" billing period in the subscription. At some point admin will spot that and freak out. The customer may think they've "skipped" a billing period and request support. And it may screw up any reporting or other operations that use the billing period.

I think we'd need to update all prepaid orders, no? Ouch.

Probably silly idea: add a "queued" state?

Sorry cross post ... wouldn't a boolean (or lock) to indicate queueing need an update hook to set that for already queued orders? Is that feasible?

OK so the state would prevent a requeue for us.

What else does a locked order imply though? What is that flag actually for?

I'd worry about further development deciding to assume only locked orders are in the queue. I also think there was some reason we don't save the order prior to putting it into checkout, which we'd have to to unlock it.

If the orders are already getting loaded and looped through then filtering on order data seems reasonable. If not and we are only querying for IDs then it probably should be a field for performance?

Because the initial job would be marked as a failure

No it's still in dunning retry, ie needs_payment.

Hmm. We are allowing users with failing payments to put the recurring order back through checkout to update card details and pay it immediately.

We can unlock it before checkout but if the user abandons the process that might present a problem at next queueing query (every 15 minutes for us).

Can we better define "meta field"?

Site builders often add fields that will not be displayed, but do need to be edited at least once.

This begs a mechanism to opt such a field in as a "meta field". Currently this usually requires a hook_form_alter() implementation to move the field into whatever structure the theme defines as the meta group. It's far from intuitive, can't be done without code, and this seems an appropriate opportunity to fix that.

Layout Paragraphs allows moving a layout section or component via keyboard shorctuts:

1. Focus the "move" link in the section or component's floating toolbar using the browser default: click it, or tab/option-tab to it then press enter. The move tooltip is revealed.
2. Use the arrow up/left and down/right keys to move the item.
3. Click return or tab to accept the move, or escape to cancel. The tooltip is hidden.

@Wim Leers:

That hero would be placed in e.g. the default layout of the article node type. It would never make sense to expose neither the text nor the image for the "Christmas hero" in Views.

I've certainly been asked to do things like a slideshow of featured articles using their hero image, article title, field from a related entity, etc. I definitely want to be able to get at that sort of thing via views.

My concern is I don't think we should be asking content-editors to 'pick the field you want to populate this prop from'. I think site-builders should make that decision ahead of time.

Strongly agree with this.

Not sure about needing to define multiple components if there is a choice of prop fields. I can see that becoming tedious.

I can see a need for allowing the site builder to configure a component that would present, say, a select menu to the editor for choosing between a couple of predefined source fields to populate a prop. The site builder would be responsible for providing good option labels and help text to support the editor.

Not MVP, maybe something for contrib if the extension point is there.

While using a value of "0" in a list (text) field is perhaps ill-advised, it should be possible, and it should definitely be possible to use a value of 0 in a list (integer) field. But that produces the same error.

I guess something is testing whether there's a value using empty() when really it should be calling isset() or a strict equals.

Re-titling to reflect the more general problem. Fortunately I found this before pushing the new field to production.

EVA is probably the most common way to accomplish what you want, if entity references or a block-based solution using the URL are not sufficient. I've been using it for years.

32 open bugs on a module with 25000 sites recorded using it is a low bug count. Only a couple of those are rated major, none critical.

The above would be great for straightforward views access to component fields, since they're just regular fields on the entity. That's been a real content model pain point with inline blocks in layouts (ie where you can't just use a simple field).

It would presumably make content moderation "just work" for multi-field components too.

How might we handle a "make this reusable" action, when the editor wants to re use a field-based component they added to this layout on another layout somewhere? That's a very common requirement.

@rgpublic: I totally agree.

We often find ourselves in the situation of wanting to update entity field values in a deploy hook. Changed assumptions, bad data entry, whatever.

Or admins need a way to generate and save a reference to an external api entity that failed to create (flaky api, whatever).

In both cases we don't want to mess with the changed timestamp (that just confuses editors), and we are not "syncing" a migration.

John Pitcairn → created an issue.

Using patch #80 against 10.2.3 allows local task tabs to highlight as active if there is any added url query.

I have not tested what happens if the local task target url itself contains a query. In that case the behaviour should probably be to match the local task specific query parameter(s) and only highlight as active if the task url query parameters match, ignoring added query parameters. @casey is this what #84 is attempting?

Yes try it.

Try uninstalling the Internal Page Cache module.

If that works, install the Dynamic Page Cache module.

^^ This. Being able to simply declare what entity list tags you depend on is a lot more transparent than having to figure out which ugly procedural hooks you need to implement (update and insert, what?), and what you have to do in those to then invalidate the entire plugin cache.

The DX improvement is more than minor IMO.

In this case the issue is simply module weight. My custom module is sorted alphabetically before "charts", so it just needed a weight decrease in libraries.yml.

Thanks @andileco for taking the time to look at this.

John Pitcairn → created an issue.

Re #14 and #15: This is not specific to multi-column fields. I can reproduce it with a single entityreference field in a view of commerce subscriptions.

I can set aggregation for the field to COUNT, and apply.

But thereafter I cannot remove or change the aggregation for the field. Clicking apply will produce the ajax error.

Un-postponing.

Note if you use a dedicated media type for SVGs (ie"logo" in my case), you can set the image formatter to output "original image" for all view modes, and that will display just fine in the media library and widget.

I think my issue summary was poorly worded...

That's what this issue is about. The regression is that there used to be a fully responsive jpg fallback, and now there is not.

The patch does not restore that functionality.

@ChristianDeLoach, could you please check the following:

The img tag should also contain a srcset attribute listing the responsive jpg versions.

If the img tag only contains a src attribute, then there is no responsive jpg support for browsers that do not support webp. There is still only a single jpg fallback.

Maintainers are not responding to contact messages, and are not on Drupal slack. I think we can consider this module abandoned.

I can also reproduce this warning when opening the media library from a paragraph edit modal.

I'm running into this error when running the views_post_update_remove_default_argument_skip_url db update during a 9.5.11-to-10.2.2 upgrade. While the null check may indeed be masking a problem with the view config dependencies, the patch at #28 does at least allow the update to proceed.

#261 and #262 will not apply to 10.2.x, needs a reroll.

Needs work for failing tests.

::findField() returns an element, pass its value to xpath.

We are no longer guaranteed a string return when finding the message field.

OK, not sure how to get this MR to test. Patch created from #16.

Actually let's fix the nits.

Re #5: I think the DrupalCheck functional js errors may relate to 📌 Fix PHPStan L2 error in traits Needs work . The problems DrupalCheck identifies in the .module file are nitpicks.

Unassigning and setting to needs review, let's test the MR.

Is this about entity reference field autocomplete?

If so, what's wrong with the established technique of using a view to provide the entity suggestions. That does allow you to specify the entity fields to search on.

If there is help text, it should not say "removed".

IMO any other library-linked paragraph should remain so, including any other copies of the paragraph in the same parent entity. Only this single local paragraph should be unlinked.

Anything else would be a UX WTF, and hard to explain.

Composer install just puts the required directory structure, drupal files and php dependencies in place. It does not install the drupal database.

You need to do that yourself, by visiting /install.php, or by running drush site:install.

You need to have created the database, db user and db password before doing so.

Maybe they are confused about how Drupal permissions operate. I've seen this sort of behaviour from "security consultants" before. If they are running penetration scans, they should be doing that with low or no privileges (anonymous or normal registered user), not as a trusted full-admin user. 

Probably just running out of php memory on the other end of the ajax request. Forget dev console for this, it's only really useful for js errors, check the Drupal logs for more accurate error messages: /admin/reports/dblog

Ha. I mean the default in the formatter, where defaults are currently hard coded. Probably has to be add an #after_build callback to the entire form.

Is any work happening @thomas.frobieter? It's assigned to you.

Is there a current workaround if I want the default for all elements and wrappers to be "None"?

By the way, all the 403 should be switch to 404 for security obfuscation.

Only if Drupal does that in .htaccess for Apache as well. It's a misuse of the response code.

Sites are free to modify the defaults for their own purposes, if obfuscation is a requirement.

Fair enough. No on second thought it's a problem that will go away eventually by itself with these fixes in.

Safari 17 is quite a high bar given Apple ties it to specific OS updates (it's the new IE). Any interest in a fallback technique with broader browser support?

Just bitten by this with a minimal install. Not the first time either from memory. MR3639 does appear to fix the problem.

Is this still a 10.x candidate or does it need to be 11.x now?

destination => $return_url->toString()

John Pitcairn → created an issue.

John Pitcairn → created an issue.

John Pitcairn → created an issue.

Is it possible to mark the composer package for 2.x as unsupported? Anyone running composer require drupal/inline_entity_form is still going to get ^2.0@RC.

Doesn't the standard entityreference formatter already include some protection against recursive rendering?

My client's expected workflow looks like this:

states:
    initial:
      label: Unpublished draft
      published: false
      default_revision: true
    published:
      label: Published
      published: true
      default_revision: true
    draft:
      label: Pending draft
      published: false
      default_revision: false
    unpublished:
      label: Unpublished
      published: false
      default_revision: true

This was biting me today as part of a broader attempt to make moderation behave the way a client expects.

My current solution is to swap out NodeModerationHandler and override ::onPresave() to avoid changing the default revision unless we are publishing. The handler is marked @internal however so that's not ideal.

Anything that can't be googled should not be an official support forum. Dries' recent Lille keynote was very big on pushing the open web - Slack isn't that.

I doubt all the devs on Drupal Slack will be all that thrilled with a bunch of non-coder support requests clogging things up either.

@Jaypan: 

The main problem I see with this is that when you google an issue, you find forum links. Slack conversations do not show. So there is no record of support.

Exactly. Slack channels are great for fast comms between developers, but if we are going to deprecate support in favour of something the DA doesn't need to maintain (if that's the rationale), then at least (say) Stack Overflow can be googled.

I doubt all the devs on Drupal Slack will be all that thrilled with a bunch of non-coder support requests clogging things up either.

Duplicate issue, your form is misconfigured for stock support. Please see this comment ✨ Support for Commerce Stock Enforcement Fixed and the rest of that thread.

I'm closing this. The solution I recommend is to build the comparison view you need, and add a rendered entity field to display the add-to-cart form for each row.

The requirements for the comparison view will be different for every site depending on the product variation fields and attributes, so I don't feel it is a good candidate for a generic solution. Existing tools should be sufficient to build what you need.

Re #66: yes, but this issue does not just affect text formats/editors.

It also affects things like views rewrites, where you might want to rewrite and add a style attribute that is benign - passing a css property value through to a stylesheet for example. No text editor is involved there.

Should probably move this to 11.x now.

Yup but any fix will be against 11.x then backported, right?

I've definitely noticed Claro blockquote styling leaks into the editor. Annoying.

I also agree with #31.

Content editors who should only interact with blocks via layout builder should not see the reusable blocks overview page or be able to create standalone reusable blocks from there.

Current MR applies to 10.1.2 and fixes it. Not able to test in 11.x at present sorry.

Yow. I can reproduce #98 as user 1 with full admin privileges.

JS console error:
ResponseText: {"message":"Non-reusable blocks must set an access dependency for access control."}

Watchdog:

Path: /media-library?destination=/node/4/layout&_wrapper_format=drupal_ajax&ajax_form=1&media_library_opener_id=media_library.opener.field_widget&media_library_allowed_types%5Bimage%5D=image&media_library_selected_type=image&media_library_remaining=1&media_library_opener_parameters%5Bfield_widget_id%5D=field_image%3A-settings-block_form&media_library_opener_parameters%5Bentity_type_id%5D=block_content&media_library_opener_parameters%5Bbundle%5D=image&media_library_opener_parameters%5Bfield_name%5D=field_image&media_library_opener_parameters%5Bentity_id%5D=2&media_library_opener_parameters%5Brevision_id%5D=2&hash=RZpw_Ue-CORgfs34fAruBGXBLZUhx_qIoGwlq0UPRZU&views_display_id=widget&_wrapper_format=drupal_ajax.

Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException: Non-reusable blocks must set an access dependency for access control. in Drupal\Core\Routing\AccessAwareRouter->checkAccess() (line 118 of /var/www/html/public/core/lib/Drupal/Core/Routing/AccessAwareRouter.php).

Or even add a checkbox to each individual theme's settings. Maybe that's a followup ;-)