bernhard

I'm having some troubles with using the renderReady method of inputfields. The first problem that came up was discussed with @adrian here: https://github.com/baumrock/RockAdminTweaks/commit/1c327039f22138725c2dfdc9e659525f2f59011b#commitcomment-142442415 It looks like the renderReady() method is never called for InputfieldCheckboxes. Another problem came up today when developing RockGrid. That inputfield needs some JS+CSS assets to be loaded whenever an inputfield of this type is rendered in the backend. I thought loading the assets in renderReady would be the right thing to do. But it does not work if the field is inside a repeater. I used this hook to fix this: <?php public function init(): void { wire()->addHookAfter('Inputfield::render', $this, 'preloadRockGrid'); } protected function preloadRockGrid(HookEvent $event): void { // if it's not the repeater field exit $f = $event->object; if ($f->name !== self::field_variations) return; // loop through all fields of the repeater and load their assets foreach ($f->hasField->fields as $fname) { $field = wire()->fields->get($fname); $inputfield = $field->getInputfield($event->process->getPage()); $inputfield->renderReady(); } } This works but it is really hacky and I'd like to have a proper solution for the problem and try to understand better what's going on and why things do not work as expected. Can anybody shed some light on this?

Hi @Christophe I can't reproduce. Please provide step by step instructions then I can try to fix it.

Thx for sharing! I'm not having any issues, so I'm wondering why? I'm using latest UIkit and latest LESS module. Do I have to adjust something specific? Would it be worth to create an issue for the uikit team so that they can account for that use case?

@FireWire have you considered using WireHttp for the requests?

Another very interesting approach by @netcarver and @FireWire:

Hey Ryan, thx for these additions! I'm wondering if there is a way to open a modal and then react/wait for something within that modal. For example we could maybe create an action for a page reference field to create a new page. When the page is successfully created in the modal and the modal is closed we could trigger the inputfield's reload event and the user could instantly select the newly created page.

@sebibu you can easily hook into https://processwire.com/api/ref/session/login-success/ and add the last login timestamp as $page->meta('lastlogin', time()) on the $user object (for example).

AI help sounds good: Certainly! You can use a hook to modify the output of a Page Reference field when it is set to "Open + Locked (not editable)" by hooking into the `renderValue` method of the `InputfieldPage` class. Here is an example of how you can achieve this in ProcessWire: // Add this to your site/ready.php or a custom module $wire->addHookAfter('InputfieldPage::renderValue', function(HookEvent $event) { $inputfield = $event->object; $page = $inputfield->value; if($page instanceof Page) { // Modify the output to include a link to the referenced page $event->return = "<a href='{$page->url}'>{$page->title}</a>"; } }); This hook will intercept the rendering of the value for `InputfieldPage` fields and modify it to include a link to the referenced page. Make sure to place this code in a file that is executed on every request, such as `site/ready.php` or within a custom module's `init` method. For more information on hooks in ProcessWire, you can refer to the https://processwire.com/docs/modules/hooks/

Seems that they dropped PW for their sites... Same here

It might also be worth mentioning that there's also a RockFrontend site profile now that has tailwindcss support: https://github.com/baumrock/site-rockfrontend ?

Hi @Ash and welcome to the forum! It sounds like ProcessWire should be a great fit for your requirements! IMHO you have two options Build a custom UI on the frontend Use the PW backend 1 has the benefit that you can build it however you want with all the tools and workflows you already know. It has the drawback that you have to build everything that is necessary (user registration, all kinds of security mechanisms etc). Basically you are building a mini-CMS for your clients and we already have a great CMS at our hands ? 2 has the benefit that it is a well established platform for content management, and what you are trying to do sounds like content management to me ? The drawback is that you have to first learn how the backend works and how you can customise it or how to develop your own modules with custom workflows. Which way is preferable depends on you, your skills and your needs (and your clients). Is design and a good UI/UX very important? It might make sense to build a custom UI. Is it more important to be cost effective? Do you want to build on a solid foundation? Are you willing to learn PW and also benefit from the knowledge for future PW projects? Then diving into PW backend development might be very worth it. I took the backend pill years ago and don't regret it ? I don't know what exactly you are asking, but the short answer is "yes". ProcessWire is great at working with data, either from the UI or also from the command line. And it has always been - see this ancient post from 2010, for example. Nowadays we even have an API for reading CSV files line by line, so an import script could be as simple as this: <?php while($row = $files->getCSV('/path/to/foods.csv')) { $p = new Page(); $p->template = 'food'; $p->parent = 123; // page id of parent $p->title = $row[Food]; $p->type = $row[Type]; $p->color = $row[Color]; $p->save(); }

Unfortunately I have no idea what could be the issue. The only thing that looks weird to me is the capital M in the template name Motif-sub-layout. I'm never using capital letters here, although I know they are allowed - so it might be totally only a personal preference and nonsense in this context. Just wanted to mention that this might be worth testing - maybe your local dev file system is not case sensitive and your remote one is, or similar? I don't know, but it might be worth a try ? Good luck! Other than that I'd try to revert as much as possible on the remote (maybe remove or uncomment almost anything in the pageclass) and try to see if it works at some point. If so, then jackpot, then you can add things back in and see when it starts to break.

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