🇷🇴Romania @bbu23

Thanks so much for confirming, reporting and helping with testing!

Thanks.

Thanks everyone.

Thanks, I also confirm that the issue has been fixed.

@kumkum29 yes, we are planning a release as soon as we have a stable dev. We're getting very close to it.

P.S. If you're experiencing "same content slides", please use the patch in https://www.drupal.org/project/swiper_formatter/issues/3488101 🐛 Display as "Swiper Entity" shows the same image in all slider elements Active until merged.

Thanks.

Hi,

I updated the MR. Please let me know if this fixes both issues.

@juagarc4 thank you for providing the detailed steps. I'll try to reproduce as soon as I get the chance.

Thanks for reporting this, but this issue is very similar to the related one. Closing it as duplicate. Please provide the information in the other ticket, since the behaviour of the output has the same problem. Thanks!

@kerrymick in this case, please describe the exact steps to reproduce your case, and when I get the time I'll check. Thanks

Did you clear the caches after applying the patch? @the_turk

Update outdated information after 4.0.1 release.

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.

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

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.

Update outdated reference

Update outdated information after release 4.0.1

Update outdated information after release 4.0.1

Update remaining information after release 4.0.1

Start replacing outdated information after release 4.0.1

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?