🇨🇦Canada @darkodev

@kevinquillen, would be great if you could have a peek at the proposed addition of an OR condition.

darkodev → created an issue.

darkodev → created an issue.

Not sure what bug I introduced, or was introduced by one of my contrib modules, but it seems to have been resolved. The Views number of items now gets overridden in my Layout Builder layouts as it should.

Thanks, @vinai_katiyar for the thorough demo video!

@ccarnnia, not sure if your issue is related, but let's close this issue to keep it clean and you can perhaps log a separate issue?

darkodev → created an issue.

Thanks.

Fixing our version to 3.0.0-beta3 until we can switch from CK4 to CK5.

Anyone else stuck on CK4 should probably do the same.

darkodev → created an issue.

RTBC +1.

The module now respects the "Require summary" field setting.

Thanks for fixing that!

I can toggle the display of the About formats link in Manage form display settings. See screenshot.

Still an issue for you?

darkodev → created an issue.

@fuchoa I wish it were that easy. We are stuck on CK4 contrib until we can manage to convert all our custom plugins to CK5 and ensure no data loss.

Just happened to us.

After updating embed and entity_embed to latest releases, got a WSOD at /admin/config/content/embed and text format config forms.

Class "Drupal\embed\EmbedCKEditorPluginBase" not found

@tarasiadis

You probably want the 10.2.2 security update

"conflict": {
"drupal/drupal": "*",
"drupal/core": ">10.2.2"
},

Attributing my contribution to my organization. Thanks for merging, @mark_fullmer!

I tested MR5 in the following forms and it works. Thanks very much for getting this far with this!

Layout Builder (my original need for this patch along with the block visibility patches in https://www.drupal.org/project/drupal/issues/2916876 ✨ Add visibility control conditions to blocks within Layout Builder Needs work ).
Works as expected, but throws an AJAX error after choosing the node type. In spite of the console error, it does load the fields and allows saving of the condition, which then works as expected.

Core Block Layout
Works as expected.

Menu Position
This module used to ship with a field value option in D7, which no longer exists in D10.
Works as expected.

I do not use Context module.

https://www.drupal.org/project/drupal/issues/3053145 ✨ Allow layout builder sections to be nested. Active

Sorry for wasting your time. A cache clear right after a composer update on ^2.0 fixed the issue for me.

darkodev → created an issue.

darkodev → created an issue.

@SecCon Not sure how much experience you have with Drupal, but the migration process from an external source usually starts with building a Drupal site from scratch, then migrating the content into the site. This means building content types and fields, taxonomies if needed, lists of content with the Views module, and customizing a base theme of your choosing. This is no mean feat and takes quite a long time. The learning curve for migrating content with the Migrate API is very steep, even for mid-level developers, which is why I suggested Feeds could work for you. You could always hire someone to do the work, but it would still need a lot of planning by you. Best of luck!

If you just want to construct your entity types manually and import CSV data into them, perhaps Feeds module is more appropriate since you can create the mappings in the UI. 

Tests failed because of my failure to fix the other sort function in linkit_profiles.inc.

Can't seem to run another test at this moment.

@jaochim, MR created. Setting required to FALSE is easiest solution, I think.

darkodev → created an issue.

Same on Drupal core 10.2.4 after composer upgrading drupal/shs (2.0.0-rc4 => 2.0.0-rc11)

Patch doesn't apply to latest stable, but can be applied manually. Any chance of a release that includes this patch? Thanks for all your work on this cool module.

Added an MR and PHP 8 test to push this along.

Ideally, you'd place a breakpoint in file.inc on a local instance and go through the backtrace to find where the failure occurs. Are you able to do that?

I can upload files just fine with the latest update, but this issue is kinda scary. We're delaying the update on prod with the hope it can get figured out so we don't run into a potential "exotic" issue we haven't tested.

I just searched my codebase and database for the string, "The image file is invalid or the image type is not allowed," but could not find it.

Which module produces this exact error string (I assume that's the place to set a breakpoint to debug)?

Easy solution with core Views:

Create a views block for page title and make it H1 in style settings and apply whatever extra classes you want on it. 

Place that block in LB layouts. 

Thanks @chrisck for the layout library suggestion.

Layout Library solves an issue I was pondering for our D7 migration where we are migrating page_manager pages to layout_builder landing pages. Rather than creating each landing page's layout directly, I can instead create a layout_library entity for each landing page with machine name nid_xxxx (where xxxx is the integer nid). This way layouts are in configuration and I just need to map the layout to the node in migration yml by the nid.

I plan to do the same for taxonomy and block layouts.

I don't only post on d.o. for others, but for myself when I forget how I did things :-)

An example of concatenating a file description value with the node title and a constant using include_source (after trying a whole bunch of process chains that did not work). There could be a better way, but I haven't found it.

Hope this help someone further.

source:
  constants:
    factsheet: 'Factsheet'

field_file:
  - plugin: sub_process
    include_source: true
    source_key: node_source
    source: field_some_file
    process:
      target_id: fid
      display: display
      description:
        - plugin: concat
          source:
            - 'node_source/title'
            - 'node_source/constants/factsheet'
          delimiter: ' '

Tried all patches for core and conditional_fields for D10, but nothing worked.

Thanks to workaround in #8. Works flawlessly for multi-select dependee fields when loading the node edit form.

#48 works well for us on Drupal 10.1.3 and Admin Toolbar 3.4.1

+1

darkodev → made their first commit to this issue’s fork.

@Spokje, there is no code to find occurrences of iframe, just a general db search in phpMyAdmin :-)

If this moves forward, there could be a programmatic search of the db to harvest all domains used in iframes. This might be problematic, though, in the case that users have embedded iframes from undesirable domains. It would be best to somehow authorize the addition of the iframe domains that are discovered in a db search.

With @Spokje "stepping away from this one," I wonder what are next steps?

We're in tricky territory in terms of getting this out to those who might need it.

The 7.x branch is marked as, "No longer developed by its maintainers."

We do, however, have a recent update in reaction in part to a 3rd party security update: https://www.drupal.org/project/ckeditor/issues/3349695 📌 Update CKEditor 4 to 4.21.0 Needs work

That update suggests updating to 4.21.0, which we know in this thread breaks iframes in certain situations and has potential to affect users beyond the database update provided here (other CK fields beyond body).

Looks like someone found a niche cleaning up Drupal code, which does need to get done :-)

https://www.drupal.org/u/dineshkumarbollu/issue-credits →

The three patch combo does not work for me, and seemingly stopped working for @liquidcms.

Thanks for the great comments, Kevin!

One of the features that we're looking for in the other thread is to allow visibility based on a field's value, for example (we have been doing this in Panels visibility rules in D7 rather than Context).
Unfortunately, it doesn't work in Layout Builder modal because of an AJAX callback route issue.
https://www.drupal.org/project/drupal/issues/2916876#comment-14286454 ✨ Add visibility control conditions to blocks within Layout Builder Needs work
https://www.drupal.org/project/entity_field_condition/issues/3248365 ✨ Core Layout Builder Compatibility - AJAX Error Active

I suppose this could be tackled in a Context with the help of your module.

Time to dive back into Context module after many years away ...

darkodev → created an issue.

Thanks for this patch.

Just a heads up for anyone else coming across this issue that iframes can also occur in fields other than field_data_body and that those occurrences need intervention beyond what the update hook here does.

To deal with other fields where iframes were embedded manually, for example, we searched our database for occurrences of "

If you don't do this, CK could potentially add empty sandbox to those iframes and break them when they are edited and saved.

Not sure there is anything this module can do about that.

darkodev → created an issue.

@joelpittet My fix addresses the primary issue in https://www.drupal.org/project/ctools/issues/3216839: →
"[...] if the relationship's context is not present, then the context passed to the relationship is whatever the variable $rcontexts was last set to in the previous loops."
"The quick fix for passing the wrong context would be to ensure $rcontext is unset/reset on each loop."

Setting $rcontexts to array() or NULL does not seem to change the behaviour of ctools_context_get_context_from_relationship(), but setting it to NULL would align it with the other issue.

Perhaps the secondary issue in https://www.drupal.org/project/ctools/issues/3216839 🐛 Incorrect context passed to ctools_context_get_context_from_relationship() Needs review about contexts qualifies as a separate issue, as it is specific to views_panes.inc?

darkodev → created an issue.

@justcaldwell, @Anybody, @ZhuRenTongKu
Entity Field Condition would be a very good solution, but it seems to cause an AJAX error when used with patches in this thread. I created a feature request https://www.drupal.org/project/entity_field_condition/issues/3248365 ✨ Core Layout Builder Compatibility - AJAX Error Active

9.2.0 using patch #111 fails on dictionary.txt because terms have been added. This seems like a moving target since terms seem to be added regularly. I added 'fieldnid' manually.

fieldnames
+ fieldnid
fieldsets

After that change, this patch does show the "Control visibility" link on blocks at node/xxx/layout for us. Not sure what's stopping it from working for @Anybody.