@dipakmdhrm I've updated the fork/MR with a slight change so that it uses the value that's set in the form array rather than a fixed 'invisible'
The patch in #14 was incorrect, a bad re-roll on my part. I've fixed this - as to whether the patch is needed or not, I don't know - I'm just updating a project using it so better to keep the change in, than removing it.
The field permissions part of the STR to might be key though?
Added a re-roll to apply to 8.x-3.6 based on patch in #4
Re-rolled the patch to apply to 10.4.x
Wasn't the max-width, but Claro adding a negative margin-inline-end which was pulling the next element inwards.
The MR resolves this and with it applied, we now see:
I've created a MR with a potential fix that seems to work in our case. The preprocess field changes the #langcode property on the render arrays where it's set to the value from the language context of the config page that the field belongs to.
With the MR applied, links to translated content now link to the language version that matches the language context from the config page, instead of the default language of the site.
After debugging and some more issue queue searching, pretty confident this is a duplicate of 🐛 ID map not copied when cloning row without destination Needs work
Yep, no problem. I've created 📌 Remove the old migrate_tools_sync state entry Active
I came across this issue after upgrading to 10.4 and looking into the state cache flag.
Our state values are all relatively small, except migrate_tools_sync that's pretty large.
We've updated the module and ran updates etc which has created the new table - all fine there.
However, should the old state entry still exist? Should it not be removed as part of the update hook?
I can't find any code leftover that would remove it so it looks like it'll persist forever unless we delete it ourselves.
Had the same issue and had to pin to a specific version in composer.json.
This fixes the issue and https://www.drupal.org/docs/develop/using-composer/add-a-composerjson-file → recommends not having the core requirement.
I assume this won't stop composer bringing in 2.1.0 / 2.1.1 for D9 unless they're removed somehow and re-released?
This patch will need work as when applied, the Webform UI stops showing any webforms in the list.
Created a MR with a fix, before, the output (for both times) was:
Executing drush content:export node --entities="11006"
[notice] Message: Successfully exported the content. You can find the exported file at the
following location:
/var/core/www/scs-export/node-article-6a914ecd-c45c-4dd9-96f7-52db833ae391_14.ymlWith the fix applied, the 2nd execution gives the output:
Executing drush content:export node --entities="11006"
[notice] Message: Successfully exported the content. You can find the exported file at the
following location:
/var/core/www/scs-export/node-article-6a914ecd-c45c-4dd9-96f7-52db833ae391_14_0.ymlwhich contains the correct filepath.
I've added a commit (I think/hope!) to the issue fork to allow publish state / unpublish state to be in the form without the other. The logic check of both not existing doesn't let 1 of the fields being in the form by itself.
mjpa → made their first commit to this issue’s fork.
mjpa → created an issue.
The plugin has the "From, Source title" hard coded for some reason. I've attached a patch that:
1. Uses the source text you enter for the figcaption
2. Doesn't wrap it in a cite element or create a cite attribute so you control the exact text
3. Change the dialog to use "Source" as a label, "Source URL" is confusing as it doesn't need to be a URL
Patch in #82 doesn't work for us, it removes the ajax_view.js changes present in #80.
#80 applied to 9.5.5 cleanly and works for us.
For us, this was caused by the following missing from solrconfig_extra.xml:
<!--
Elevator
7.0.0
-->
<requestHandler name="/elevate" class="solr.SearchHandler" startup="lazy">
<lst name="defaults">
<str name="echoParams">explicit</str>
<str name="df">id</str>
</lst>
<arr name="last-components">
<str>elevator</str>
</arr>
</requestHandler>