Let me say, I adore this logo. Also, I would vote we refer to this as the "drop capacitor" logo ;-)
I have run into this error many times and have had to patch many sites with the solutions kindly provided here. It would be amazing to see a fix for this in Drupal 11.3. Santa? I promise I've been a good Drupalist all year.
I will point out that #148 suggests that a "fix" is to uncheck your content type in the content translation interface, save, and then check it again and save. While this does indeed allow translations to be saved, effectively this resets the field translatability, making all fields translatable. IMHO this doesn't make sense, especially for things like entity reference fields (where it often makes more sense to translate the referenced entity instead).
Thanks for raising this. First off, on a matter of semantics: it took me a minute to get my head around this issue because you speak of making locations "content entities", when in the Drupal-verse this is the most generic term for any instance of a class that extends Drupal\Core\Entity\ContentEntityBase, including nodes. So in the current implementation, Location nodes that you create are content entities. I'm pretty sure what you mean is that you considered making the locations a new, potentially custom content entity type.
The challenging balance of working on a project like this is that you can never accommodate all the conflicting assumptions that others will bring to the subject. You assume that most sites won't want a "title" but it's pretty common for Locations to have some kind of label (even if you consider it a "name" or other identifier) and if you think about how something like Google Maps works, when you do a search the results all come up with a textual representation. Also, Drupal and a fair bit of its Symfony underpinnings often expect to be able provide a text representation of an entity, so if you omit this as a base field, you need to provide some mechanism to generate the text instead. Since you raised Storage Entities, I can tell you that Storage does include its own mechanism to generate text labels in cases where a user-provided label doesn't seem necessary.
A lot of work has gone into Storage Entities. A big part of the motivation for creating it was the decidedly non-trivial amount of work required to implement a new content entity type. For a lot of use cases, adding a bundle to a non-node, existing content entity type is sufficient. Sites that require more complex or specialized implementations are welcome to use ECK or implement their own content entity types in code.
I can see an argument for moving Locations to use Storage Entities instead of nodes, particularly since Storage Entities can allow or disallow direct access with a simple configuration change. I suppose I went with nodes for Locations originally because my own experience with implementing locations on Drupal sites was often that direct access was intended. Also, since it wasn't clear to me that a significant portion of sites would NOT want to allow direct access (or want to label their locations), adding another contrib dependency didn't seem justified.
I'm certainly open to more discussion on this topic. My initial reaction, however, is that I don't see the potential benefits of such a change as outweighing the disruption it would cause. If you want to create a separate project (e.g. Locations Storage) using the approach you have in mind I would be happy to link to it from the project page here.
As long as the field is configured to automatically create new terms, any specified tags that don't contain a numerical value will be automatically created by Drupal core, so we don't need to worry about the AI use case. So, where the field is configured this way the automator only needs to parse the suggestions returned in the AI response, and add numerical IDs to existing terms, and leave the rest unchanged.
Since this issue mentions Linkit as a contrib module that needs to be supported in a 1.0 release, I thought it would be appropriate to mark ✨ Linkit should recognize Canvas pages as targets Active as a related issue. Not sure if that should really be fixed, in Canvas, however.
The div wrapper was intentionally added in #3159065: Wrap details content in a div.details-wrapper to match the expected markup by drupal/collapse → to match the markup expected by the shim in Drupal core. I recognize that was years ago and caniuse now lists browser support for details elements at around 96%. TBH I'm not sure if core even contains this shim anymore, but keeping the shim should allow details elements created by this module to match any created by core.
I would personally lean towards making this configurable, but I'm also open to other perspectives.
I added video tags to the IS but I suppose drupal.org doesn't support those, which does make sense. you can use the links in the previous comment to see the problem (first video) and then the problem resolved with the patch applied (second link).
This was with a recent install of Drupal CMS → . Maybe the problem is specific to having that as a starting point?
How I experienced the problem is this:
On a canvas page, if I click to select a meta image, the media library modal launches. If I select an image and click the button to "insert selected", however, the media field reverts to its previous state. No thumbnail of the selected image is shown, and the text under the field says that 0 of 1 media items have been selected.
With the patch applied, the field works as expected, showing the thumbnail for the selected image and the text stating that 1 of 1 media items have been been selected.
I will also point out that this patch is being used in production currently.
I ran into this same issue, and can verify that the proposed code resolved my issue. I'm tempted to mark this as RTBC, but it should probably be an MR first.
I'm using a fresh install of Drupal 11.2.4 and Storage dev-1.4.x. I am able to successfully access the storage overview page without or without existing storage entities in the database. Clear steps to reproduce are needed before I can evaluate the proposed changes.
I just tried to follow the steps to reproduce on a fresh install of Drupal 11.2.4 and the latest code in the 1.4.x branch. I was able to access the Revisions page and even view a revision without an error. Can you review the steps again and see if something else is needed to see the error?
@fathershawn Thanks for your work on this. I can't seem to reproduce a scenario where storage entities don't already work this way. Can you add steps to reproduce?
Thanks everyone. Merged this in, and will try to roll a new release shortly.
@megan_m this sounds like an important fix but I don't see an MR. Any chance you have the required code change handy?
Adding the checklist preferred by the project ownership team. Please correct if there are any inaccuracies in the information I have entered.
It's worth mentioning in this thread that Smart Date's included support for Fullcalendar View is deprecated and will be removed from an upcoming v5 release. Anyone wanting to use Smart Date with an interactive calendar should transition to the Fullcalendar → project instead, which includes a variety of improvements, including the processing optimization suggested here.
My own personal preference would be to use the form called out in #10 as the place where Automators are defined. Then, the field widget is the only place they need to be associated with a particular field (since the action elements are currently only for forms). Maybe the widget configuration piece could allow an Automator to be defined in the settings tray or in a modal?
I think it makes sense for Automators to be able to share configuration between fields, as this will may it easy for the same element to work in the same way in different places on the site. If a different field needs an automator to work in a different way, we should allow Automators to be easily cloned.
@dieterholvoet I fully support your application to be a co-maintainer, and would appreciate your help. Unfortunately, I do not have access to manage maintainers.
I was added as a maintainer by eme → in #3175187: Offering to co-maintain Form mode control → so it seems the best path forward is to contact him.
Thanks for your work on this! My only concern is that only updating the order in the scheduler won't fix how the time slots are order elsewhere, particularly the schedule. So we should either make sure the schedule has the proper sort defined, or have this updte the order of the taxonomy terms themselves
seantwalsh → credited mandclu → .
phenaproxima → credited mandclu → .
matthews → credited mandclu → .
I'm tempted to say this is expected behavior (knowing how core works) , but I can appreciate that from a site builder viewpoint this would be unexpected.
I'm tempted to say that this should be a feature request, to provide a means (maybe automatic?) to reset the ordering for a taxonomy vocabulary when the generator is run.
matthews → credited mandclu → .
At some point it might be helpful to have a release of this module that required Devel >= 5.4.0 and the main Kint module
Thanks for identifying this, and for providing a fix. Merged in.
volkswagenchick → credited mandclu → .
mandclu → created an issue.
mandclu → created an issue. See original summary → .
I have a project that started throw 15 phpcs errors of the exact type mentioned in the IS and also one other, all in .yml files. I can't personally see what useful feedback we would get from running a php check against .yml files.
This was addressed in previous commits, in particular New and updated block placement
Moving this to Event Platform since the cause probably needs a fix in the config page admin labels.
Also, updating the IS to reflect the new understanding, as well as the fact that the order of the fields has changed.
seantwalsh → credited mandclu → .
seantwalsh → credited mandclu → .