Leaderboard

As @Tiberium suggest, the best way would be to run a PHP script from an external file (how I'd do it) or in a template. Or an alternative would be to set up an Admin Action: https://processwire.com/modules/process-admin-actions/. If you're not familiar with running scripts that access the API, I suggest starting with https://processwire.com/docs/front-end/include/. And another helpful page is https://processwire.com/docs/start/api-access/. In all cases, the procedure would essentially be this. First rename field sand add them to templates manually through the admin interface (if necessary, temporarily rename fields, then name them what you finally want when everything is in the right place). Then set up a script to loop through the pages with the source of the images, copying each image from the old field to the new field on the relevant page. (If each field has only a single image, you won't need to loop through the images in the field.)

I've read several times that slow page loads came from lots of pages being loaded into memory when loading the page. This might be due to a poorly configured page reference field (eg a selectbox with thousands of pages) or maybe another module with a totally different purpose. I think you are right that an autocomplete field should not cause any issues. I'd try to look into the debug tools first and see how many pages are loaded on that initial iframe request. You should see that in the bottom right corner if debug mode is on.

You have an eagle eye @PWaddict😀 I have fixed this issue now. If you have the latest version 2.2.33 installed, you need to replace the file https://github.com/juergenweb/FrontendForms/blob/main/FrontendForms.module. Otherwise you can update the module as usual and you are done.

@Juergen I just tested it and it works but now there is a new issue. On console I'm getting this error on all admin pages except the FrontendForms page module. Uncaught TypeError: $(...).imagepicker is not a function Check the initializeImagePicker function.

Hello @PWaddict I have added selectively loading of the JS and CSS files in the backend. To test it, you only need to replace the file https://github.com/juergenweb/FrontendForms/blob/main/FrontendForms.module once more. It contains now additional methods to check if the files should be loaded on the current page or not. It was not so easy, because the image picker files of FrontendForms will also be used by other modules from the FrontendForms family and I have to take care of it. Best regards

@Juergen Problem solved. No longer getting these files on frontend. Thank you. The only problem needs to be solved is to not load them on every admin page.

I'm talking about backend files that getting inserted on frontend. I removed everything (header, footer etc.) from my template and just added only the execution line of LoginRegisterPro: <?php namespace ProcessWire; echo $modules->get('LoginRegisterPro')->execute(); ?> and as you can see from the screenshot below the FrontendForms files I mentioned on the previous post are getting inserted. This happens on every form of LoginRegisterPro (login, register, edit profile, forgot password) which are all exist on the same template and triggered by the above 1 line of code. These files are also inserted on every admin page too. You're right.

Version 1 is here! https://github.com/orgs/NativePHP/discussions/547 Mobile apps capability in the works: Not surprised; given that Caleb Porzio also wrote Alpine.JS 😊.

@bernhard NICE!

@szabesz I think the phrase "everything necessary" might be worth considering here. A class ideally just has one responsibility. Page instances are there to provide an interface to one page's content and be swapped in and out of memory on demand. When there are things like hooks going into a Page, that changes the role completely. If you start doing this a lot on a large site then it may affect scalability. Maybe it's fine for one individual installation or another, however. In your case, this isn't an issue, as you've solved that concern with a static method. I think that's okay for an individual installation, but it wouldn't be okay for PW to suggest for everyone because it's not multi-instance safe. The core avoids also static methods when possible because they are disconnected from any instance of the class. When there are static methods, it's always worth looking closer if it's worth the convenience (sometimes it is) or if they would be better off somewhere else. Using hooks in your /site/init.php, /site/ready.php or /site/templates/admin.php (when appropriate) is a safe strategy, but I agree it's not great if you have a ton of them. At that point it might be good to have an autoload Module, or to start including your own files from one of the previously mentioned ones. But if you find it beneficial to use /site/classes/YourPageClass.php then also consider a separate class (ProductPageTools.php?). Rather than having a static method, you can have a static variable in your ProductPage class that refers to that instance, but there will only ever be one of them, and it will be multi instance safe. Page classes already do this for a lot of things, delegating to other classes (PageTraversal, PageValues, PageProperties, etc.) for code that can be shared among all Page classes. There's only ever one instance of those classes, no matter how many Page class instances there are. And they are all multi-instance safe. This also keeps the memory requirements of the Page classes very low, since the Page class has very little code itself, and mostly delegates to other classes where the same single instance operates on all Page classes. class ProductPage extends Page { static private $tools = null; public function wired() { parent::wired(); if(self::$tools === null) self::$tools = $this->wire(new ProductPageTools()); } } class ProductPageTools extends Wire { public function wired() { parent::wired(); $this->wire()->pages->addHook('saveReady(template=product)', $this, 'hookSaveReady'); } public function hookSaveReady(HookEvent $e) { // ... } } Maybe you have a method with a lot of code that you want to be callable from ProductPage (any number of instances) but maintain in ProductPageTools (only ever one instance). This is how the core delegates to other classes and limits the scale and scope of classes that may have many instances. class ProductPage extends Page { // ... public function foo() { return self::$tools->foo($this); } } class ProductPageTools extends Wire { // ... public function foo(Page $page) { $result = ''; // A whole bunch of code to generate $result from $page return $result; } } If the strategy you are using now works well for you then I'm not suggesting you change it. But just wanted to point out the strategy I'd suggest as a scalable and multi-instance safe one that also maintains separation of concerns and keeps the Page class from becoming complex or heavy.

Does anybody else feel like the login screen could use a revamp? While it might not be the most important thing in the world, first impressions count. On large(r) screens the login form seems to get lost in the upper third. The rest of the admin looks a lot cleaner and more deliberate. A few tweaks would go a long way in making the login screen work on all device sizes. Those are two custom styles I've been adding to my sites lately, one PW-branded and one not. No markup changes needed, just CSS. This second one borrows heavily from Twill's login screen. The floating environment label has turned out to be really useful to see at a glance if one is editing on staging or live. Not sure if there's a way to make this 100% core compatible.