Hi, thanks for reporting this. We noticed issues with Views just recently. Could you please confirm that this is happening with Views only? Thanks
Patch files are no longer recommended, use merge requests instead → .
Added the proposed patch to MR, and fixed small coding standards.
Tested and works as expected.
I have provided a fix for this, thanks again for reporting this issue.
We made a small typo mistake when porting from version 1 to version 2. Please try out the patch and let us know if everything okay now.
Regarding the Proposed steps, 8 & 9 are not necessary, but of course can be tested. This bug can be reproduced for any entity reference, and in this particular example after step 7 the block can be added directly to the block layout and will have the same behaviour.
Though from your screenshots it might look like the keys are empty, so yes, in that particular case, the cache keys array will only contain the same key for all which is incorrect. Makes sense, I'll investigate.
Hi,
Thanks for reporting this issue, I'll try to reproduce it when I get the chance.
The cache keys is an array of parts. In the case of node, a example is "['node', 5, 'teaser']". This means that the teaser representation of the node will be cached, but in Swiper's case it was a conflict because swiper is altering the representation. By adding the "swiper-slide" key we are creating two different "cache keys" depending on the scenario. And in theory, they are supposed to be unique. Randomising is not an option, so I first need to try to reproduce your scenario and investigate what happens to understand better.
More information about the original issue here: https://www.drupal.org/project/swiper_formatter/issues/3395406 🐛 Swiper formatter fails to wrap row in swiper-slide div intermittently Active
Marking this page as incomplete in preparation of version 4.0.1 that brings multiple changes to the UI and terminology.
Marking this page as incomplete in preparation of version 4.0.1 that brings multiple changes to the UI and terminology.
Marking this page as incomplete in preparation of version 4.0.1 that brings multiple changes to the UI and terminology.
Marking this page as incomplete in preparation of version 4.0.1 that brings multiple changes to the UI and terminology.
Marking this page as incomplete in preparation of version 4.0.1 that brings multiple changes to the UI and terminology.
Marking this page as incomplete in preparation of version 4.0.1 that brings multiple changes to the UI and terminology.
Marking this page as incomplete in preparation of version 4.0.1 that brings multiple changes to the UI and terminology.
@jcl324 that's great! Thanks for checking and confirming!
Thanks @nk_, I applied the patch in dev version.
@jcl324 could you please check again on the latest dev version? Note that there might be newer commits as well, so please make sure to run drush updb when you update to latest dev version. Thanks
As per @kumkum29 and @nk_ and no other objections, I've reduced the step form 0.5 to 0.1
Just by a first look, I can tell that we're missing the update hook, so marking this as needs work.
On the other hand, in the linked documentation there's a note for the use with looped slides, maybe it would be good to have it in Drupal as well.
And last but not least, I tried just to enable the grid and my images were at height 0, couldn't see anything. Is there other setting that could conflict this? I was using the most recent default values (I also rebased your branch). We had work on fixing the schema.
Hi mlo,
Thanks for the report & proposed solution.
We will review when we get the chance.
Thank you for your answer on the "Type" thing, seems fair enough.
As for "Menu group", "Menu collection" etc. I'll stick to the initial proposal, as at the moment I consider a must to have the "export" and "import" words present, agreeing with your last statement:
Or maybe it again just could be a cause of confusion, introducing new concepts ...
Thanks for your feedback as well!
So I'm trying to avoid having opened issues whenever I can. This means, that I am trying to take a decision whether to go forward with this or cancel it.
I created a kinda POC with how this replacement would behave/look like with the mention that the proposed "Export menus" and "Import menus" menu items are implemented as "Menu exports" and "Menu imports". The reason is simple: Menu exports is the plural of Menu export and those pages are listings of Menu export or Menu import entities.
On the other hand, I had/have some inner conflicts with this. I admit that it looks & sounds better for sure, but going back to the source issue, I'm just curious why "Content Type" is fine but not "Export Type". After all, this is a type of export and "Article" is a type of content.
Furthermore, if I decide to advance with this, from now on there will be a distinction between UI text and code text, which by itself is not a problem, but let's call it "a very small bifurcation".
Will be playing with it, thinking, but looking forward to your response @ressa
@jcl324 I skipped that point because that is confirmed by @nk_:
A bug to confirm - there is no option to select Title or Alt field as a Caption on the formatter settings.
But I confirm that I don't see those options either.
bbu23 → created an issue.
That's great!
I'm glad that everything is working as expected, and the issue has been resolved!
Thank you!
@nk_ I'm not quite sure what the test is. I did the following in Drupal 10 (because vanilla Drupal 11 is not ready for this yet):
- I created a taxonomy vocabulary with an image field with ALT and TITLE enabled
- I configured the display to first show "Swiper images", later "Swiper images Dialog"
- I added a two terms with each 2 or more images
The behaviour was ok for images on the term page, but for dialog if I closed the dialog and reopened it, it was empty.
Later I added a term reference field to a node.
I tested the following scenarios:
- Term reference -> non-swiper rendering, so showing the swiper from term through node
- Term reference with swiper formatter: here, of course a case that probably should not be used, the slider had two arrows each side, so 4 arrows in total, and the behaviour was mixed.
In none of the cases I could not do anything with the title or alt fields.
Actually, do you confirm that you introduced the email and password and saved the configuration here "/admin/config/search/search-api/opensolr"? And after that you triggered the Test connection?
Hi Alex,
Thank you for reporting this issue.
I think we're missing a "Start over" or "Reset Credentials" option for this particular case. Do you have access to command line to execute a command or are you restricted to using the UI?
Actually, I forgot to update the README. Reopening.
Yeah, it's very strange indeed, and I am trying to remember, but I'm not 100% sure. I know I was exploring the Project Browser at some point, and it could be that I found it there. But still, not sure. It could be long Google search or Project Browser.
Oh, I see. Well, each module with their pros and cons it seems.
The format option has been added and the menu description updated.
This should resolve the remaining feedback.
Thank you!
I like it!
Yes, naming naming... :D
Perfect, in this case I'll use that description, it's perfect. And update the format. Thanks!
Indeed, Menu Export did not have a Drush command, a major problem/inconvenience for me, but that and other reasons are the core of my decision to create my own module, including the configuration.
I didn't know about Structure Sync either, I actually discovered it after I finished the development stage of version 4, when I was doing research about "Similar modules and how are they different" for the module's page updates.
Still, both Menu Export and Structure Sync do have the configuration sync principle, which is why my module's core functionality needs to continue on the route it was born in (independence from config).
On the other hand, I'm glad to hear that Structure Sync fits your needs, they also seem to have more control over partial and full imports, which my module lacks.
Thanks!
The --format option will be added to the new commands based on the discussion in the related ticket.
Closing this, with the mention that the --format option will be resolved in the related ticket.
Thanks @ressa. You know, I was a bit surprised that in your yesterday's feedback there was nothing about this. Because I had troubles naming it hahah
My dilema was that I didn't want to have something that says "this is the only Drush option". Because, as we both know, Drush is available in both scenarios. The only difference is that this "quick export" is offering codebase only Drush commands that can be used immediately with minimal configuration if the user wants to change it, whereas for more stable/regular imports/exports, the user would have to go through multiple steps to be able to use Drush if they want.
So, my question is: if we call it "Drush Export/Import", isn't it implying that this section is the only Drush section available? That's where I added "quick". Now, I was not necessarily pleased by the "Action" name, I added this because I was thinking that it reduces "Import/Export" into one word, but it is not ideal. Also, I was thinking of potentially creating a form of "quick action" (let's say) or two forms "quick import" and "quick export" to import/export on the fly menus using GUI and using the contents of the Configuration Entities for one time situations. Like maybe when I want to quickly download a menu from production, instead of creating a config entity before, to have this possibility. And that's how I arrived to that.
Thank you for proposing this, but in this particular case I will mostly reject it.
The reason is that when I created this module, I wanted a clear separation from the Drupal's configuration folder. This is one major difference with Menu Export and Structure Sync modules. I wanted full control of the exported files, I wanted them to be seen in GIT easily from the start, to encourage the user to have them placed outside the Drupal root's directory and to leave the user the choice if they sync them or not. Also, these files are not configuration, so in my opinion they don't belong in the configuration directory just by their role.
Furthermore, the Quick Action Settings form values can always be overridden in settings.php. So, if GUI needs to be avoided in some cases for the exported path, it can always be done directly in settings.php.
The only part that I agree with, and actually considered it while I was working on the related issue was the --format option. This we can definitely add.
🙌🙌🙌
@ressa thank you as always!
Marking as Fixed.
Thank you for your feedback, I was expecting feedback especially in this direction, so that's perfectly fine.
I do prefer aliases due to faster typing, so I might just mention both to cover both. I'll be back.
I pushed the initial changes, drush updb needs to be run.
I'm setting the issue status to Needs work while I work on updating the README file and test on multiple versions.
@ressa I created an issue for the quick export/import, I will push a first batch of code in that direction if you're interested to check it out.
https://www.drupal.org/project/menu_migration/issues/3486499
✨
Bring back the possibility of exporting and importing menus directly using drush
Active
bbu23 → created an issue.
Yes, I might have included extra concerns unnecessarily. :)
Based on your research, indeed it requires many changes if we tackle every occurrence. I'll be thinking of it, I also agree about the effort, so we'll have to see. It's definitely doable, but it's very time consuming as you mentioned.
Thank you for your analysis, but I wouldn't go that far. I don't want to change what a user cannot see.
But I do agree with the naming in the UI, now I will review this and take a decision.
Appreciate it, and glad it works as expected.
Since you tested it, I'll update the credit. Thanks!
Fixed, the file path now shows in both Source and Destination columns.
Needs Documentation updates & change record in the next release.
Valid points. I updated the key, thanks!
Adding a note that we might need to review README and Documentation for these changes in case it's needed.
Here's my conflict:
1. I agree that there should be only one menu item within the Development section
2. I dislike the fact that there will be a longer path of clicks to get to the desired pages
Therefore at the moment I'll accept the changes, and see if there will be feedback on this in future versions. After all, there's the option of Shortcuts available to everybody. We'll see how it goes.
Thank you!
Sounds good. I'll play with both scenarios then.
Whether it's just the Codebase or more, I'll have to make a general solution. Thanks!
Valid point this one. Though this would require changes to the plugin system.
Maybe adding a additionalInformation method to the plugins to cover generality could be a good approach. I wonder though if this should be a separate column or together like the screenshot. Of course, at the moment we have only the Codebase plugin that would give extra info, but idk if there are other plugins in people's custom code or not, and how would that look like.
I can work on this unless you have the intention to do so.
Hahah, yes the naming sometimes can be the harder part!
Sure, sounds like a plan! Thank you!
I appreciate it, thank you!
Yes, my_menus seems good.
Sure, I'll think about this one (the Drush support).
Yes, it might be because I wanted probably to have examples from both Code export and Download export. But maybe it should be with both in both cases, and not "random".
When I was working on early Drupal 11 solution the admin toolbar module was not available for Drupal 11. What I was trying to do, was to display "Menu Migration" as a parent section within the Configuration area with the children "Export Types" and "Import Types" underneath. If I remember correctly, I couldn't easily achieve that within the Development section. So, I did something that's similar to the Devel generate module that has a second menu "Generate" under Configuration with the intention of skipping a click for the Import Types. Thoughts?
I have to admit it sounds much better 😁
You have the green light, I like how it sounds and it makes total sense. To think about it, I had a bit of troubles finding names for that I think I just went with the actual name of the entity type. So, please proceed, and then we need to update README as well, and when I do the release we need to update the Documentation, and with occasion update the screenshots for the other feedback as well from the Documentation (the one you mentioned about the IDs naming).
Thank you
No problem, @resssa. I'm glad that YAML works as well as expected.
I did see the suggestions about the naming, indeed that makes sense though I think what I wanted to avoid was to make it look like you have to use one menu as a name. I was thinking of more scenarios, from one menu, to menu per environment to menus grouped together.
Indeed, the examples that I posted in the documentation are far from what would be considered as good examples, so I'll consider your suggestion and update the page (hopefully in a timely manner).
As for the Drush command, I'll definitely re-evaluate what I was thinking of after the version switch. I'll see what I can do, I agree about the convenience for Drush users mainly, but not only.
Thank you for taking the time to evaluate the new version and contributing as always!
I agree with the proposed changes. Thank you, @ressa!
Hi @ressa,
Thank you for the feedback.
Indeed, I don't deny that having to create export types and import types could be both convenient and inconvenient. I was thinking at some point about maybe creating a 3rd option something like "quick action" where you could export one or more menus on the fly. That idea was never evolved into a plan, since I haven't received yet any feedback, but if you're the first to mention it, I might consider getting back to it to make the module more flexible for both sides.
As for the notes in the documentation about the JSON and YAML files, I am 100% positive that both YAML and JSON work with Drush. I even retested on my Drupal 11 to ensure what I am saying. Could you please describe the steps to reproduce Drush not working with YAML? At the moment I removed the lines that were saying that Drush does not support YAML, as I could not confirm this.
Thank you!
Correcting: both YAML and JSON formats work with Drush. Removing the line that says otherwise.
Hi,
Thank you for reporting this issue.
Our aim is to have version 2 compatible with PHP 8.3 minimum. The decision is not yet final.
Considering that both version 1 and version 2 are compatible with Drupal 10, and Drupal 11 requires PHP 8.3, we plan to keep version 1 for Drupal 9 and Drupal 10, and to use version 2 for Drupal 10.3 and above. This would also allow us to implement the necessary changes to take full advantage of the performance boost provided by PHP 8.3.
We'll keep this open until evaluation and decisions are final.
We'll keep the ticket open as it's related functionality is being worked on & reviewed. We will close this when a new release is being made.