Jump to content

Multiple admin pages from ONE ProcessModule?


owzim
 Share

Recommended Posts

I want a settings page under /Admin/Setup for admins and an interface for the CMS user under Admin/ directly. Would I have to have two ProcessModules for that, or is it somehow possible to manage that logic in only one ProcessModule?

Thanks.

Link to comment
Share on other sites

Ha it's always the same with me. Right after I asked a question the light bulb pops up over my head.

I can simple have ONE ProcessModule, install it in /Admin/Setup and then create a new Page under /Admin and assign the same Process (edit/Process -> select) to it.

Or of course do that in the install method.

PW is awesome, have I mentioned that already?

Edit:

Then again, is it even wise to have two admin pages handled by one process? What I come across now is that since the two pages are aimed at different user roles I would have to manage both differently in one module. The handling of URLs is also nasty since I have to check under which parent the current process runs, for each executeSomething method.

Perhaps not such a good idea? The "need' stemmed from the idea to have both pages share methods and objects.

Link to comment
Share on other sites

Are you talking about the permission to access the module? Or different behavior based on roles?

The first one could be solved pretty simple like this:

    public static function getModuleInfo() {
        $permission = (wire('page')->parent->name == 'setup') ? 'role-a' : 'role-b';
        return array(
            'title' => 'Foo',
            'summary' => 'Bar',
            'permission' => $permission,
        );
    }

  • Like 2
Link to comment
Share on other sites

Thanks @apeisa and @Wanze for the suggestions.

Are you talking about the permission to access the module? Or different behavior based on roles?

The first one could be solved pretty simple like this:

    public static function getModuleInfo() {
        $permission = (wire('page')->parent->name == 'setup') ? 'role-a' : 'role-b';
        return array(
            'title' => 'Foo',
            'summary' => 'Bar',
            'permission' => $permission,
        );
    }

I know, thanks, but that's what I meant. I have to handle permissions manually, which I think is not that desirable.

I ended up creating a base class:

class MyModuleBaseProcess extends Process {
    // useful shared process methods here
}

And then have the both individual ProcessModules extend from it:

class ProcessMyModuleSetup extends MyModuleBaseProcess implements Module {
    // individual methods here
}

// and

class ProcessMyModuleUI extends MyModuleBaseProcess implements Module {
    // individual methods here
}
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Similar Content

    • By sms77io
      Hi all,
      we made a small module for sending SMS via Sms77.io. It supports sending to one and multiple users.
      You can download it from GitHub and follow the instructions on how to install it - it is quite easy. An API key is required for sending, get yours for free @ Sms77 and receive 0,50 €.
      Hope this helps somebody and we are open for improvement suggestions!
       
      Best regards
      André
    • By opalepatrick
      I see old posts saying that repeaters are not the way to go in Custom Process Modules. If that is the case, when using forms (as I am trying to do) how would one tackle things like repeat contact fields where there can be multiple requirements for contact details with different parameters? (Like point of contact, director, etc) or even telephone numbers that have different uses?
      Just for background I am creating a process module that allows me to create types of financial applications in the admin area (no need to publish any of this, pure admin) that require a lot of personal or company information.
      Maybe I am thinking about this incorrectly?
    • By jonatan
      So... I thought (for some stupid reason I can't even recall now no wait now I remember.. I wanted to hide the "Trash" for "editor" role users) that it'd be super duper smart to "Enable access control" for the field "process" on the admin template.... Really really stupid.... Now all I get is:

       
       
       
      – when I go to mywebsitedomain.com/admin
      but.... my website domain.com and all its subpages works perfectly fine! So it's ONLY the /admin (processwire) which throws a 503 at me. 
      🥵🤯☠️💩😭😱
      S.O.S.
    • By MoritzLost
      Sorry for the convoluted title. I have a problem with Process modules that define a custom page using the page key through getModuleInfo (as demonstrated in this excellent tutorial by @bernhard). Those pages are created automatically when the module is installed. The problem is that the title of the page only gets set in the current language. That's not a problem if the current language (language of the superuser who is installing the module) is the default language; if it isn't, the Process page is missing a title in the default language. This has the very awkward effect that a user using the backend in the default language (or any other language) will see an empty entry in the setup menu:

      This screenshot comes from my Cache Control module which includes a Process page. Now I realize the description sounds obscure, but for us it's a common setup: We a multiple bilingual sites where the default language is German and the second language is English. While the clients use the CMS in German, as a developer I prefer the English interface, so whenever I install a Process module I get this problem.
      As a module author, is there a way to handle this situation? I guess it would be possible to use post-installation hooks or create the pages manually, but I very much prefer the declarative approach. The page title is already translatable (through the __ function), but of course at the time of installation there is no translation, and as far as I'm aware it's not possible to ship translations with a module so they are used automatically. Could this situation be handled better in the core? I would prefer if the module installation process would always set the title of the Process page in the default language, instead of the language of the current user.
    • By MoritzLost
      Process Cache Control
      This module provides a simple solution to clearing all your cache layers at once, and an extensible interface to perform various cache-related actions.
      The simple motivation behind this module was that I was tired of manually clearing caches in several places after deploying a change on a live site. The basic purpose of this module is a simple Clear all caches link in the Setup menu which clears out all caches, no matter where they hide. You can customize what exactly the module does through it's configuration menu:
      Expire or delete all cache entries in the database, or selectively clear caches by namespace ($cache API) Clear the the template render cache. Clear out specific folders inside your site's cache directory (/site/assets/cache) Clear the ProCache page render cache (if your site is using ProCache) Refresh version strings for static assets to bust client-side browser caches (this requires some setup, see the full documentation for details). This is the basic function of the module. However, you can also add different cache management action through the API and execute them through the module's interface. For this advanced usage, the module provides:
      An interface to see all available cache actions and execute them. A system log and logging output on the module page to see verify what the module is doing. A CacheControlTools class with utility functions to clear out different caches. An API to add cache actions, execute them programmatically and even modify the default action. Permission management, allowing you granular control over which user roles can execute which actions. The complete documentation can be found in the module's README.
      Plans for improvements
      If there is some interest in this, I plan to expand this to a more general cache management solution. I particular, I would like to add additional cache actions. Some ideas that came to mind:
      Warming up the template render cache for publicly accessible pages. Removing all active user sessions. Let me know if you have more suggestions!
      Links
      https://github.com/MoritzLost/ProcessCacheControl ProcessCacheControl in the Module directory CHANGELOG in the repository Screenshots


×
×
  • Create New...