Leaderboard

Limited Module Edit Allows non-superusers to edit a limited selection of modules. Of course, there are good reasons why non-superusers are normally not allowed to access the configuration screen of modules so use this module with caution. Usage 1. Install Limited Module Edit. 2. In the module configuration select one or more modules in the "Modules enabled for limited editing" field. When you enable a module here a corresponding "lme" permission is installed. For example, if WireMailSmtp is enabled here then a permissioned named "lme-wire-mail-smtp" will be installed. 3. For any role that you want to allow to configure the previously selected modules, enable the "module-admin" permission and the "lme" permissions for any module they may configure. 4. Users with these permissions will now see a special Modules section in the main menu that provides links to configure only the modules they have been given permission for. These users are not allowed to install modules nor are they allowed to uninstall the modules they have permission to configure. https://github.com/Toutouwai/LimitedModuleEdit https://processwire.com/modules/limited-module-edit/

@MarkE, I've released a module that allows non-superusers to configure selected modules, which might be helpful for your current project:

As a longtime photo enthousiastic i decided to show my work to the "world" What else could i do than use processwire? My Dutch site is viewable at: https://foto.markveldman.com Mark Veldman

Nice site. My only critique would be to remove the UIKIT transition from the thumbnails. It gets tiring very quickly and it's kinda gimmicky.

@MarkE The Modules class supports a lot of different options for this, and it figures out which you are using automatically according to how you've defined it. The one that I prefer to use is your second example, that is not static and has the InputfieldWrapper $inputfields as the argument. The static method is the old/original way from when ProcessWire first was released (13 years ago), and it was used primarily so that one could configure a module without booting up an instance of the module. Later on (like ~8 years ago?), the Modules class was upgraded so that it could instantiate the module without initializing it, which made the static option obsolete. The only reason ProcessWire still recognizes it is for backwards compatibility, or if it happens to be preferred by the module developer for one reason or another.

After a previous request for Webp support (6 years ago, times flies…) that Horst and Ryan kindly introduced in PW 3.0.132, I'm back with another request for a new image file format, AVIF, which has landed in almost all browsers. I'm actually surprised no one here in the PW community has been asking for AVIF support in ProcessWire as it seems to be provide much more consistent gains in compression and greater relative quality over Webp, and of course over good old JPEG. My experience using it definitely confirms this. I've been using Cloudinary to serve AVIF images to the browsers that support it, but of course I'd rather not use a third-party service, and use it natively in ProcessWire. Imagemagick supports AVIF if I'm not mistaken. Anyone else is interested?

Module help you to create and use set of components to utilize in your ProcessWire. You can find more info and an examples on Github repo : https://github.com/trk/Component/tree/main

Good day, all the super clever RockMigrations users! I am just starting to get my head around this super module. I've got what seem like a bug when using installModule() method. As the title says installModule() does not actually install the module when run the 1st time, but only downloads it. When the method is run the 2nd time, the module is actually installed, but not until then. I've already created the github issue, but double posting it here to find out if someone else is facing the same issue. Seems to be an critical one. Just want to make sure it is reproducible.

https://www.bmt.net.nz/ This project began as a project to convert a 20 year old Microsoft Access membership and musical production database to a cloud based system. I completed that over a year ago, but then the organisation realised they wanted a new website, and much of the data was already in the system I'd built for them to manage their membership and shows. Building the public frontend required adding a few more fields on the backend, and reorganising some of the data, but most of it was there already. I've used Lister Pro extensively in this project and it's also my first project using RockMigrations. RockMigrations has proved really helpful in adding new fields, testing, then applying to the live site, and although there's a bit of work to go, the aim is to use RockMigrations to enable the whole setup to be installed as a module on top of a clean ProcessWire installation, as I suspect the setup should be useful for other groups, either with or without customisation of the frontend. Other modules I used were Formbuilder Pro for a membership form, Import Pages from CSV (to import exported data from Access database), Wiremail Gmail, to enable emailing to gmail addresses. I also wrote a custom dashboard module and updater. I wrote a modified version of the ListerPro action Send Email to enable sending HTML formatted emails.

thanks for this - i'll see if i can fix that asap.

This is what people call incredibly useful! Thanks for sharing, as always!

For any future readers of this thread, here is a module for this purpose:

@Jim Bailie Your _init.php is called for every $page->render(); so if you've got more than one page rendering in the request, _init.php will be called for both of them. One example of that would be if your template file does a wire404(); then _init.php would be called for the page that started rendering, and also for the 404 page. The reason for this is that _init.php usually establishes variables and such that you might want to populate or use in your template file or in your _main.php, so it has to be called on every page render. If you have a need for it to only be called once, such as if you are defining functions in it, then just move the contents of your _init.php to another file, like _init-once.php (or whatever you want to name it), and then do this from your _init.php: include_once('./_init-once.php');

Just came across this need for the SEO module as well. I have posted this request: https://github.com/processwire/processwire-requests/issues/170 Until there is some progress on that, here is my hacky solution. I am sure it could be improved, but it works for now. $this->addHookBefore('ProcessModule::executeEdit', function($event) { if(!$this->wire('user')->isSuperuser() && $this->wire('input')->get->name !== 'MarkupSEO') { throw new WirePermissionException('You do not have permission to configure this module.'); } }); $this->addHookAfter('ProcessModule::executeNavJSON', function($event) { if(!$this->wire('user')->isSuperuser()) { if($this->wire('input')->get->site === '1') { // note \/admin\/module\/ - if your site admin is at /processwire/, then use: \/processwire\/module\/ $event->return = '{"url":"\/admin\/module\/","label":"Modules","icon":"plug","list":[{"url":"edit?name=MarkupSEO","label":"MarkupSEO","icon":"gear"}]}'; } else { $event->return = null; } } }); That results in this - Modules > Site contains just the SEO link and all the others are empty. Thanks @Robin S for the headstart on this!