RockAdminTweaks: Modular Tweaks for ProcessWire Backend ✨?️

[bernhard]

Hey ProcessWire RockStars! ?

Ever felt like your ProcessWire backend could use a bit more... pizzazz? Or functionality? Well, it's time to roll up your sleeves and dive into the world of RockAdminTweaks! ??️

Creating tweaks is as easy as smashing a power chord on your guitar! If you've got cool features from AOS you'd love to see, why not port them over? We even have a GUI for creating new Tweaks! Let's make the backend rock even harder!

Github: https://github.com/baumrock/RockAdminTweaks
Modules Directory: https://processwire.com/modules/rock-admin-tweaks/

Docs: https://www.baumrock.com/processwire/module/rockadmintweaks/

[netcarver]

Great, thanks @bernhard.  I have a small number of tweaks (some from AdminOnSteroids) in my public tweak pool already - looks like they will be compatible with this version of your module if the namespace is unchanged.

[bernhard]

1 hour ago, netcarver said:

I have a small number of tweaks (some from AdminOnSteroids) in my public tweak pool already - looks like they will be compatible with this version of your module if the namespace is unchanged.

What is your intention with this module? I think it would make more sense to add the tweaks directly to RockAdminTweaks, no?

https://github.com/netcarver/RockAdminTweaksPool/blob/697240eb651dd873585b7f2630a81f2d905192ca/assets/RockAdminTweaks/AdminOnSteroids/BypassTrash.php#L28 --> this is not needed any more, because tweaks are only loaded in the backend, so it will always be template == 'admin'

Regarding styles and scripts: I've added a "loadJS()" method on the Tweak base class. This will automatically load the corresponding js file from the tweak. See docs here: https://github.com/baumrock/RockAdminTweaks/tree/main/docs/assets

Personally I'd prefer to have all the JS in dedicated JS files. It's a lot easier to write, a lot easier to read (no escaping, working color highlighting etc) and it's also easier to develop and debug (as you can set breakpoints, for example). I think the same concept makes sense for CSS files as well, what do you think?

I'm just not sure from a performance perspective. Does it matter if we load multiple scripts with just a few lines of code? Would it be better to inline them into the HTML? But I don't like this ugly script and style injections via str_replace... So I've just added loadCSS() method as well!

Regarding the AdminOnSteroids folder: I think it's nice to mention tpr's module, but I'd like to group tweaks based on what they do or where they add magic. For example I've added a "PageList" folder for tweaks that relate to the pagelist/pagetree and a "Forms" folder that relates to all kinds of forms or inputfields (page edit etc). If you have suggestions for other folders please let me know. The folder "AdminOnSteroids" makes no sense in my opinion.

[netcarver]

Hello @bernhard

9 hours ago, bernhard said:

What is your intention with this module? I think it would make more sense to add the tweaks directly to RockAdminTweaks, no?

Ok, it actually isn't a module, it's a collection of tweaks. From my point of view, I'd rather just install the exact tweaks I'm going to use in to the assets/RockAdminTweaks/tweaks folder. If every possible tweak is accumulated in the RockAdminTweaks repo, wouldn't all of them will be copied in to the site when the module is installed or updated? In that case, RockAdminTweaks is likely to become somewhat bloated over time, and bloat is something you seemed to be moving away from when I read the original RockAdminTweaks documentation...

Quote

...One option is to use AOS which comes with lots of improvements but also comes with bloat and bugs and it is not actively maintained any more...

The repo I started doesn't have to be the only pool. I started it to learn how how to write tweaks, and to experiment with how a pool could be accomplished. If the tweak pool idea survives, I'd actually much rather have a the pool under the baumrock/ namespace.

There are probably other ways of dealing with avoiding bloat + provide a library of tweaks as well, but it seems to me that to avoid bloat the tweaks need to live somewhere outside the module, or there needs to be some mechanism (other than manually deleting unwanted tweaks from the server) that allows the install of the exact tweaks required.

10 hours ago, bernhard said:

Personally I'd prefer to have all the JS in dedicated JS files. It's a lot easier to write, a lot easier to read (no escaping, working color highlighting etc) and it's also easier to develop and debug (as you can set breakpoints, for example). I think the same concept makes sense for CSS files as well, what do you think?

I'm just not sure from a performance perspective. Does it matter if we load multiple scripts with just a few lines of code? Would it be better to inline them into the HTML? But I don't like this ugly script and style injections via str_replace... So I've just added loadCSS() method as well!

Yes, having those in separate files would be much better than inlining them in the addStyles() method.

10 hours ago, bernhard said:

Regarding the AdminOnSteroids folder: I think it's nice to mention tpr's module, but I'd like to group tweaks based on what they do or where they add magic. For example I've added a "PageList" folder for tweaks that relate to the pagelist/pagetree and a "Forms" folder that relates to all kinds of forms or inputfields (page edit etc). If you have suggestions for other folders please let me know. The folder "AdminOnSteroids" makes no sense in my opinion.

That makes sense.
 

[bernhard]

Hi @netcarver thx for clarifying. I wouldn't call such a collection "bloat". By bloat in AOS I meant that all features are not well organised. They are all put into the same files leading to large files with lots of hooks etc.; If one feature makes troubles it's hard to find all related lines of codes. Or if you want to remove it you risk to break something else. In RockAdminTweaks all tweaks are isolated and well organised, so that's not a problem at all.

Also tweaks are only loaded if they are activated so it shouldn't be a problem to have many tweaks in the module performance wise.

PS: I changed the place for tweaks from assets to templates, because multilang features don't work in assets!

[dotnetic]

18 hours ago, bernhard said:

Personally I'd prefer to have all the JS in dedicated JS files

Yes, please keep them separate for the reasons you mentioned.

I will also provide some features/tweaks inspired by AdminOnSteroids.

I would love to see the folder structure replicated as grouped collapsibles in the RockTweaks config. 

[bernhard]

1 minute ago, dotnetic said:

I would love to see the folder structure replicated as grouped collapsibles in the RockTweaks config. 

I decided to go with one inputfield checkboxes per folder, so that we can use shift-click to toggle all checkboxes of that field at once. If it were multiple nested fields we would have to check/uncheck every single checkbox.

2 minutes ago, dotnetic said:

I will also provide some features/tweaks inspired by AdminOnSteroids.

Great, thx! ? 

[adrian]

Hey @bernhard - I am thinking of revisiting this module now that it seems to be getting some traction but have two questions before I start pulling out the key things from AOS that I need.

1) What about having subfolders for each tweak so that we don't end up with a mess of php, js, css files for multiple tweaks in the one categorizing parent folder?

2) I am also thinking about a replacement for AOS's Assets Paths > Admin CSS and Admin JS feature. Perhaps it's a simple matter of creating a custom local tweak that just calls loadCSS() and and loadJS() for all those random tiny tweaks that are small enough and don't need a specific hook (and therefore PHP file). Any thoughts?

Thanks.

[bernhard]

Hey @adrian thx for your suggestions!

12 hours ago, adrian said:

1) What about having subfolders for each tweak so that we don't end up with a mess of php, js, css files for multiple tweaks in the one categorizing parent folder?

Initially I didn't want that. The focus was to make it as easy as possible to create new tweaks, which meant just creating one file in the dedicated folder and that's it. But thinking about it and the number of tweaks growing it might be better to have them in folders, so please check out v1.6.0 which works as you suggested. Also we have a gui for creating new tweaks, so it's no difference in easy of use and some tweaks might ship with additional assets, so having them in a dedicated folder will definitely keep things cleaner.

12 hours ago, adrian said:

2) I am also thinking about a replacement for AOS's Assets Paths > Admin CSS and Admin JS feature. Perhaps it's a simple matter of creating a custom local tweak that just calls loadCSS() and and loadJS() for all those random tiny tweaks that are small enough and don't need a specific hook (and therefore PHP file). Any thoughts?

I don't know what this feature is and how you are using it, but yes, adding custom JS/CSS is as easy as creating a tweak and calling $this->addJS() and $this->addCSS(). For CSS we already have /site/templates/admin.less;

PS: This was a quite painful update. I removed a folder while working on this update and accidently this folder was /site/modules with lots of updates to RockCommerce and RockGrid ? Shit happens. At least I was able to restore some of the work with the VSCode timeline feature...

VSCode is fortunately smart enough to only TRASH folders and not delete them, so everything was still in my bin ? 

[adrian]

Thanks for the subfolders - much better for complex tweaks, especially those that require additional assets like the AOS column break I just ported over.

I know about admin.less and I do use it. I guess I kinda of forgot in this context because I've been loading an admin.css via AOS for my standard tweak for so many years now.

[adrian]

@bernhard - what do you think about compiling, minifying, and caching the css and js assets into one single file each?

I just worry about how many extra requests all these tweaks will end up being.

BTW - I have more AOS ones coming :)

[bernhard]

Hey @adrian I've also think of that, but I didn't find a reliable source that told me wich approach is better. I understand that it's a lot of requests, but on the other hand the browser only loads those files once and then has it cached anyhow.

And having those files separate means that we could load assets only if they are really needed. This is one point that I wanted to ask anyhow. Thx for your PRs! You are loading all the assets at ready() as far as I saw, and I was wondering if it could make sense to load them only if needed, for example the checkboxes could maybe only loaded if a checkboxes field is rendered on the page?

But yeah, maybe it would be easier to compile one single js and css file whenever the module config is saved and then just load that. I think it would be easier in many ways. Also then we could load css+js files automatically with every enabled tweak.

One problem that I see is that some tweaks do things for superusers only and that's easily doable with separate files, but it's not doable if we compile everything into one file.

Any input welcome, I'm not sure yet what the best way would be ? 

PS: Could you please make your pull requests to the DEV branch and not MAIN?

[bernhard]

PPS: The next thing I'm wondering is if we need a second info param that holds a more detailed description. Some tweaks are not really obvious even for me...

[adrian]

You make some very good points - conditional loading of js/css in the php file does make things much easier for sure (like your superuser only example) and it would be painful to handle this any other way, so maybe keeping things as is will be fine.

Sorry about the PRs to main - I didn't check if you have a dev branch. Are you OK handling the current ones as is so long as I modify the upcoming ones?

I think an additional notes parameter could be useful. Perhaps also a link parameter that could automatically populate those info icons you added to a couple of tweaks within the description. Maybe also an author parameters (maybe GH username) so it's easy to keep track of who needs to be contacted for support going forward? Of course, the other approach to this would be something like what I did with AdminActions - see Robin's addon action maintained in his own repo (https://processwire.com/modules/admin-actions-replace-home/). I like the idea of separate maintenance without the need for PRs, but it would also be a pain for others to find all the tweaks, so probably a bad idea in reality.

 

 

[bernhard]

17 minutes ago, adrian said:

Sorry about the PRs to main - I didn't check if you have a dev branch. Are you OK handling the current ones as is so long as I modify the upcoming ones?

No worries, I have no guidelines in place so nobody can know. Once I tried to protect the main branch from PRs but then something else was not working any more (I think automated releases)... But I think with this module and if it's only about new tweaks it shouldn't matter at all where the PRs want to merge, I'm not sure, I'll try that out tomorrow ? 

17 minutes ago, adrian said:

I think an additional notes parameter could be useful. Perhaps also a link parameter that could automatically populate those info icons you added to a couple of tweaks within the description. Maybe also an author parameters (maybe GH username) so it's easy to keep track of who needs to be contacted for support going forward? Of course, the other approach to this would be something like what I did with AdminActions - see Robin's addon action maintained in his own repo (https://processwire.com/modules/admin-actions-replace-home/). I like the idea of separate maintenance without the need for PRs, but it would also be a pain for others to find all the tweaks, so probably a bad idea in reality.

Great input. I've thought of a new parameter like "help" or something, and maybe one for "author" to give proper credits and one for "maintainer" if that's someone else (like you or @netcarver porting over tweaks from tpr/aos). "help" would be markdown syntax and show up in a modal. author/maintainer could be icons ? 

I don't think that I like the idea of having tweaks spread around several repos of several people! The module is MIT, so I'm happy to maintain it for now and if something should happen anybody could take over.

[adrian]

Hey @bernhard - I think there's a bit of a problem with storing the enabled settings in wireCache. The cache can be manually cleared for a variety of reasons, and also really important is the fact that the default expiry is 24 hours which makes it pretty useless for this purpose :)

Why can't these be stored in the module's config settings?

[bernhard]

4 hours ago, adrian said:

Why can't these be stored in the module's config settings?

Thx, makes sense! I've fixed that and merged almost all of your PRs ? 

[bernhard]

Another update: More info() settings!

Please check out v1.8

[bernhard]

• RockAdminTweaks v1.9.3: Some bugs where fixed thx to @adrian