This patch for me does indeed fix the Route "entity.file.edit_form" does not exist type errors. However for our use with paragraph library items, it introduces a new issue, which is that the cog wheel, as seen in the image at the top, is now active and clickable.
Clicking on it takes you to a white page with a message that says something like:
The type (paragraph) of the embedded entity (PARAGRAPH LIBRARY LABEL > Paragraphs, ID: 123456) does not support neither editing nor canonical linking mode.
While this fixes the error from occurring, it introduces a user editing experience that is worse than the original problem, from my testing.
Here is the patch with the fix
devanbicher → created an issue.
Thank you for such a quick turnaround on this issue!
Here is the patch to fix the issue
devanbicher → created an issue.
Here is my patch to add the above functionality.
Note I am checking that a paragraph is a layout paragraph with the following code:
$behaviors = $paragraph->getAllBehaviorSettings();
$is_layout = isset($behaviors['layout_paragraphs']) && (count($behaviors['layout_paragraphs']) > 2);If there is a cleaner or preferred way to check that a paragraph is a layout paragraph, please let me know and I can update my patch.
devanbicher → created an issue.
I worked on this issue on the backend with @bradwade.
I am commenting here to suggest closing this issue and to warn anyone about going down this development path.
Our intended outcome was to have changes to Single Directory components to be automatically compiled into the appropriate storybook stories for use on one our of development environments. Ideally we didn't want to have to commit the storybook story files into our repository for cleanliness and consistency. Additionally these files are not used in our production environment, just in a development environment that is setup to have storybook available.
I spent time abstracting the associated drush command, storybook:generate-all-stories, in this module into a custom, globally available drush command so that we could run this command in our github workflow that builds the storbook stories, without bootstrapping drupal. In theory nothing in the drush command file StorybookCommands.php requires drupal after some tweaking to the code.
For example you can change Drupal\Core\Url::fromUri to a static url if you know what it is ahead of time, which you would if you already have this setup for an environment. Similarly \Drupal::root() can be converted to Drush::bootstrapManager()->getRoot().
However after much trial and error it turns out that somewhere along the dependency injection pipeline the StoryRenderer object needs Drupal and this storybook module enabled to setup the twig environment that is also used to construct the storybook files. So ultimately drupal and this module is needed to run the storybook:generate-all-stories command even if you move the code for the command into a custom drush command outside the drupal root.
We still chose to not include the storybook story files in our repository. Instead we created a github workflow that is triggered on adding a specific, storybook, label to a Pull Request. In this way any pull request that updates components used in storybook will trigger a workflow that, amongst other standard tasks in for our PR's:
- spins up drupal with ddev
- installs a new site with a standard installation
- enables this storybook module
- runs the
storybook:generate-all-storiesdrush comand
In this way we avoid boostrapping drupal unnecessarily in a workflow specifically needed only for storybook updates, on every PR. While also still minimizing the overhead for generating these files in a github workflow, and not commiting the story files into the repo.
Hopefully this helps any developer or team who might want to have a similar outcome to ours.
devanbicher → created an issue.
The attached patch provides support for the field described.
devanbicher → created an issue.
devanbicher → created an issue.
devanbicher → created an issue.
devanbicher → created an issue.
For me, using D10, php 8.1 the above 2 patches don't work, I tried 91 in combination with the D10 upgrade patch but also couldn't get it to apply after several attempts with some of the D10 patches.
But anyway the relevant issue with patch #93 is when trying to edit an existing template I get the following error:
TypeError: Cannot access offset of type string on string in Drupal\ckeditor_templates\Form\CKEditorTemplatesEntityForm->form() (line 136 of modules/contrib/ckeditor_templates/src/Form/CKEditorTemplatesEntityForm.php).
Note the actual class you'd be using in your code is: \Drupal\Core\Entity\RevisionableStorageInterface
The methods in that class are the same.
See https://api.drupal.org/api/drupal/core%21modules%21node%21node.module/fu...
and see the class definition here:
https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21...
devanbicher → created an issue.
devanbicher → created an issue.
devanbicher → created an issue.
devanbicher → created an issue.
devanbicher → created an issue.
The Automated D10 compatibility fixes have been merged into the Dev version of the module, which at this time is the only active version of the module.
devanbicher → made their first commit to this issue’s fork.
I was having trouble generating my patch above, which doesn't seem to be working for me (for ckeditor_templates version 8.x-1.2).
So I literally just modified the patch file in #64 with my relevant change. You can feel free to delete my above comment. (#68).
Here is the comment again to make deleting my above comment easier.
I've created a patch off of #64. In my comment above, the relevant line:
$thumb = $this->ckeditorTemplateConfig->get('thumb')[0];
Was throwing a console error locally if there was no thumbnail icon selected for a template, since there was no [0] index in the array to reference. In my patch, I simply amended the line to be
$thumb = $this->ckeditorTemplateConfig->get('thumb')[0] ?? '';
The rest of the code correctly handles $thumb being '' if no thumbnail is selected for the template.
I've created a patch off of #64. In my comment above, the relevant line:
$thumb = $this->ckeditorTemplateConfig->get('thumb')[0];
Was throwing a console error locally if there was no thumbnail icon selected for a template, since there was no [0] index in the array to reference. In my patch, I simply amended the line to be
$thumb = $this->ckeditorTemplateConfig->get('thumb')[0] ?? '';
The rest of the code correctly handles $thumb being '' if no thumbnail is selected for the template.
This is mostly working well for me testing locally on Drupal 9.5.8 and php 8.1.
But I'm getting an error from not having a 'Illustrative Image/Icon', aka ''thumb', for any given template. That or the alternative field seems to be required, however the error I was getting from the console after clicking on the button is coming from ckeditor_templates/src/Plugin/CkeditorTemplate/ConfigTemplate.php on line 95 which is
$thumb = $this->ckeditorTemplateConfig->get('thumb')[0];
So we need a check for that value, and/or requiring the thumb field when creating a template.
Once I added an image to all my templates everything seems to be working fine.
Fixed with merge of 3348784-switch-markup-strategy
devanbicher → created an issue.
I agree with approach 2. Portability across webforms seems like a nice advantage. Potential translation issues don't seem as important if that issue hasn't been raised before, but hopefully that is fixable should that situation arise.