I haven’t tried to recently but the linked patch in the original comment is what was what was required to get this module to install at the time I made this issue.
drakythe → created an issue.
I can confirm this is an issue, and that it can actually be replicated using Chrome browser (at least on MacOS) by using the viewport emulation feature of the developer tools. As long as you select a device that makes it emulate touch it will error in the same way.
We examined the mmenujs.com version of the menu and discovered that it has no instances where the parent level menu item is also a link. It is possible this is a problem with the mmenujs library itself, though I didn't dig deep enough into their repo to see for myself if that was the case.
It appears to be 2 anchor tags inside of a single li element that causes the problem. The problem seems to be that the maximum width of the first anchor tag goes super wide and pushes the second anchor tag wrapping the ">" graphic off the visible canvas. Occasionally this even results in all of the ">" graphics vanishing from the menu on affected devices, though we can't seem to consistently make that part happen. We have applied a temporary fix by manually assigning a maximum width using media queries. Our next step is to add our own supplementary JS to properly calculate the maximum width and set it in circumstances where that is necessary.
drakythe → created an issue.
drakythe → created an issue.
+1 for the patch fixing the issue. I don't have time today to look into the failing tests but I'll add it to my list if I get any in the next couple of days.
Weirdly our user had NO access to the menu at all, but the menu entry was still being changed every time they saved the node in question. As an experiement I gave the user the accesses needed to edit the menu and it still changed the parent menu item. I could load the node up with User 1 and with the restricted user in two separate browsers and User 1's edit view had the correct parent menu item on load and the restricted user did not.
Attempting to maintain the security considerations I offer this patch. If the password field is empty it loads up the callback object entity and if that entity is not new then we access the existing config and set the password field to what it already is in the database. If it was already empty no harm no foul, but if a password exists we don't lose it.
Attached is a patch file for anyone who would like these change and is using cweagans/composer-patches.
I've done an initial commit to 3293176-support-for-custom branch that pulls the hardcoded workflow value and instead loads the default commerce_order_type and pulls the workflow ID from there. I do check for a null value in case the default order type has been deleted, in that case I set it to fallback to order_fulfillment_validation. Otherwise no other changes. (I did add a line to the README.md file to explain where the state change option set is coming from)
I'm marking this as "Needs work" because while this works for simple commerce sites it would not work well for sites with multiple checkout workflows that use different status sets for each. I'm not sure what the best way to handle that might be though. My instinct is add a field to the Views Bulk Operations configuration screen on views and assign the product type's workflow you want assigned to that particular view. I'm unsure how that can be achieved only on Order views and whether that value can be saved into the current DB structure and then later checked for use. Alternatively a settings form could be created which lists out every Order view and let administrators set the Order Types that way. Again though, will need to figure out how to filter views displays down to Order Views that have VBO fields on it.
I'm also very unsure if that extra part is even necessary as the branch has enough changes in it to work for probably a great majority of Drupal commerce situations, so it could be merged in for the time being.
drakythe → made their first commit to this issue’s fork.