bernhard

Another update: More info() settings! Please check out v1.8

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

Yes, translations are saved in in /site/assets/files Enter some-unique-string-german in one of your fields Save the page Search your codebase for the string "some-unique-string-german" And you'll know where PW stores that information.

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 ? 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.

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...

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?

Hey @kaz you can simply check for the opposite: <?php if ($global->businesshours && $page->id !== 1127): ?> <?php include('businesshours.php'); ?> <?php endif; ?> Which means if we have businesshours AND the page id is not 1127 then include ... Note that there is a difference between !== and != (and also === and ==) // Using == $var1 = "5"; $var2 = 5; if ($var1 == $var2) { echo "Equal"; // This will output "Equal" because values are the same after type juggling. } // Using === if ($var1 === $var2) { echo "Identical"; } else { echo "Not identical"; // This will output "Not identical" because types are different (string vs integer). }

Hey @adrian thx for your suggestions! 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. 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 ?

Thanks for mentioning this. It's a great module and I've been using it myself for a long time, but @tpr has moved on (last AOS commit was 4 years ago and last login was 08/2023), so I've been trying to build something that allows for a real community effort where everyone can easily contribute. We'll see how it works ?

Thx to @netcarver this is now also included in RockAdminTweaks - a module intended to be a collection of all those little admin tweaks and helpers, easy to enable/disable and easy to develop, see this example (also from @netcarver). Compared to AOS, which is/was a great module, RockAdminTweaks has all tweaks separated into folders and dedicated files, so both developing new tweaks as well as maintaining existing ones should be a lot easier than with AOS (we even have a GUI for adding new tweaks...). This is what we have so far: And here the prev/next links on page edit (with nice uikit tooltips that appear instantly rather than after a delay): Contributions welcome

Sounds cool! Do you have any screenshots to share? I guess it also looks cool ?

Interesting idea @Jonathan Lahijani and thx for the input @netcarver! Is something like this also a problem? https://github.com/baumrock/RockFrontend/blob/107af5b51930d0589ecc0a882e46372b640eb6f9/RockFrontend.module.php#L26-L29

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. Great, thx! ?

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!

Please have a look at RockAdminTweaks: Both things you mention have a tweak to solve it. You could also open an issue in the PW issues repository!

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.

Hey guys, please check out the new version of RockAdminTweaks which now even has a forum thread ? Would be great to get some PRs with tweaks! @netcarver I decided to rewrite the module because I didn't like some aspects of the old one. @Ivan Gretsky I've just added those tweaks to RM because I was lazy and I did not get a single feedback on that RockAdminTweaks at all. But I agree that tweaks have nothing to do with RM, so I'm fine with moving them away from RM into a dedicated module. Do you have time to help with that?

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/

Yeah, that can be a good approach, see https://youtu.be/7CoIj--u4ps?si=q1RnzHLNWwt15TlE&t=1715 (ALFRED) for this. It might not be the 100% solution (in terms of UI/UX), but it might probably be the best in terms of cost/benefit.

Would be nice to share the whole hook ?

Haha, so true. How often have I heard "super easy, super simple..." ? I agree with most of what @wbmnfktr said, but IMHO if you don't use the PW backend you probably lose one of the main advantages of PW over laravel et al. You have to build all the forms, all the logic and all the underlying concepts on your own. Have a look at https://www.youtube.com/watch?v=MYyJ4PuL4pY for example. When you watch this video you'll see so many things that are so much quicker when using PW + backend. Do I say you should use the PW backend? No, but it's probably too early to ditch it. If the design is important it's probably easier to build something on your own, but it sounds like a quite technical project with tech-savvy users I guess, so using the PW backend should work quite well?! You could also just replace the things you want to have different and build your own admin theme. For example you could totally replace the main menu bar / header and leave everything else as it is. 80-100h sounds sporty to me ?

I don't think so. When I asked Ryan recently about modifications for our admin style he said he usually does those small modifications with JS. Not very pretty, but on the other hand this might be more robust than str_replace (which is not pretty either).

Ah, didn't know that existed! thx ?

I thought exactly the same, but I think he wants to show the published date and not the modified date? So if anyone edited an already published blogpost the date would NOT change. At least that's what the hook does as far as I understand. Maybe this shows that the naming of "$blog->date_modified = $page->date_modified;" might not be ideal ?

This might also be helpful, I don't know, I tried ? https://youtu.be/ncS36UqaBvc?si=SYhVc_qcaN5lneDP&t=355 All the best for your journey!