Thanks @brandonlira - it should be a simple case of setting the module up and taking screenshots please. They can be added to this ticket and then added to the main page (by a module admin)
aaron.ferris → created an issue.
aaron.ferris → made their first commit to this issue’s fork.
aaron.ferris → created an issue.
Appreciate late to the party, but this is possible in 2.x
Actually I can reproduce this, the issue is that the redirect_path is being converted to String(), but the contents of that are nonsensical even if you have a redirect such as /node/1. I can however see that the redirect is called continuously.
I can't reproduce this, but then I can't reproduce the redirect at all, so this appears to be broken.
Thanks for that, ive tweaked the message as providing a new notice per sub module could've been cleaner.
(As attached)
Code looks good, ill merge this when the pipeline finishes.
aaron.ferris → created an issue.
aaron.ferris → created an issue. See original summary → .
This is the case on 2.x, appreciate it's 10+ years late to the party mind.
Pulled this down and tested it, seems to work as expected. Previous code had am in a 12 clock format, at 12:58am
With the new change, this shows as 12:58pm.
Screenshots attached
Thanks all.
Reviewed, looks fine to me, thanks all.
Thanks, reviewed looks OK to merge.
Had a quick look at this, I don't think its simple as adding dependencies because bat_roomify is showing as only being compatible with ^D11
We may need a maintainers input for intended usage.
aaron.ferris → made their first commit to this issue’s fork.
aaron.ferris → made their first commit to this issue’s fork.
aaron.ferris → created an issue.
aaron.ferris → made their first commit to this issue’s fork.
Im seeing the same notice, although the Delta feels a bit odd in its original state, doesnt this mean every element _weight array has the same delta? I think we can reintroduce the variable to prevent the notices, but not sure I fully understand the original use.
Pushed an initial change to https://www.drupal.org/project/jstimer/issues/3511227 📌 Move Javascript out of PHP files Active for this.
Thanks looks good, couple of comments.
aaron.ferris → created an issue.
Made a start on this, it's functional to the point of working the same as the old behaviour, just from libraries/preprocess. Ive removed all the JS building code.
We need to test this further with how flexible it can be in adding new widgets, as the hook to build the widgets is gone.
Made a start on this, it's functional to the point of working the same as the old behaviour, just from libraries/preprocess. Ive removed all the JS building code.
We need to test this further with how flexible it can be in adding new widgets, as the hook to build the widgets is gone.
aaron.ferris → made their first commit to this issue’s fork.
aaron.ferris → created an issue.
aaron.ferris → created an issue. See original summary → .
Ive just tested this change with admin toolbar enabled, im not seeing any issues with the Admin toolbar drop down anymore.
This looks good to me. With these changes the module installs correctly on D10.4, I can see the various widget options in the admin form.
Thanks @NexusNovaz ill pull this down and take a look.
aaron.ferris → created an issue.
aaron.ferris → created an issue.
This could be because the JS the module creates is expecting a 'clock type' to be defined, whereas this will only be the case once the modules config has been saved.
Im seeing JS errors related to this:
this.props = {clock_type:$clock_type, size:200};
Because $clock_type is empty = JS errr related to the comma.
The 'widgets' folder will need some attention, this would be better as a 'modules' folder, with each sub modules .info file also needing some attention for D10+.
Seems the dev branch has changes for D10+, id propose we look to get a release (also moving away from the legacy branch).
1.x = D7/8+
2.x = D10/11
Edit - possibly fixed in https://www.drupal.org/project/superfish/issues/3281847 🐛 Expanded option has no effect Active ?
I don't seem to be able to reproduce this, can you please include complete testing steps and the actual structure of your menus?
Example of what I see, a menu item with children
<li id="main-menu-link-contentbecb029d-7246-454e-a323-9c2ffbf4b2e5" class="sf-depth-1 menuparent" style="">
aaron.ferris → created an issue.