marcus

It's important to remark that templating systems (twig, etc) or "MVC-like" approaches to separate concerns and click-and-grab-a-theme systems are different kinds of animals I don't imply that you meant that, teppo, just for fellow readers of this thread...

Really interesting discussion here! Many very important aspects are already mentioned, many good points are made. But: reading the WPTavern / "30 minutes" article, I stumbled over one particular sentence: Wouldn't that be a nice idea? At your first login, right after the installation process (where such a thing would be misplaced). This welcome screen could contain: If you are a designer, then (intro, links, resources). If you are a developer then (intro, links to official tutorials, resources) and look at the beauty and effectiveness of this: $echo $pages->get("/products/2010/")->find("template=faq, body*=Tobiko")->first()->url; Such a screen could at least give a tease to the experienced developer to find out more. Therefore, the choice of links would be crucial. But, fortunately, an official set of tutorials is on the rise. And maybe, with such a screen, PW could increase the possibility to stand the "trial of 30 minutes." And for people like me, who start with a blank profile anyway you could offer an option to disable: $config->showWelcomeScreen = false, or so.

Sorry for double posting again. But I set up a small site with better explanation and documentation of this approach: http://blueprint-wireframes.com/

Thanks a lot - this works like a charm! My next step is to compare the current user's roles to the ones in the allowedRoles array. Currently, the solution is to extremly simplify the user roles output in order to compare it to another simple array (the one coming from the original approach, exploding a string) via array_intersect. Although this works it feels wrong somehow. Will be checking the output of $this->allowedRoles now!

Prerequisites: Basic knowledge of git and git submodules A git hosting solution (e.g. GitHub) No aversion against bash commands Once you've built a couple of websites with it, a set of your own personal must-have modules emerges. For me, such a module and always the first install of the day is Soma's MarkupSimpleNavigation. But there's also MarkupSitemapXML. And so on. Depending on your usage of ProcessWire, the type of pages you build with PW or your customers, your set of modules may differ. Installing modules and functionalities that you'll need in most instances should be an automated and easy process. ProcessWire itself offers a range of possibilities to do so. First, there is installation via ClassNames: In Backend, chose "Modules", then "New" and paste or type in the class name the desired module established in the PW ecosystem, for example `LoginPersist`. From that point on, the particular module gets downloaded and installed within two clicks and just a matter of seconds. Rinse and repeat until your starter module set is complete, but be sure to memorize or note the correct class names. Secondly, you can create an own starter site profile with your modules in it. This not only gives you the means to bootstrap in a module related way but also many possibilities for template and field groundwork. But a disadvantage (on the module site) remains: Unless you control and update all the modules in your site profile, only certain, possibly outdated versions will be installed - and you have to manually update them afterwards. For my last few projects I found a third way: Bundling all starter/must-have modules together in a git repo, using the modules as git submodules. After ProcessWire installation on my local machine, I just clone this bundle and recursively pull every module's master to its latest commit. An example (with my set of starter modules): cd site/modules && git clone --recursive git@github.com:marcus-herrmann/ProcessWire-BootstrapModuleSet.git && cd ProcessWire-BootstrapModuleSet && git pull --recurse-submodules What does this code do? At first, let's assume you've navigated via the terminal to you ProcessWire's installation root folder. Afterwards, these steps follow: 1. Change directory to module folder 2. Clone your bundle repo 3. Change directory to the folder created by aforementioned bundle repo clone 4. Pull all submodules to their latest commit That's all. After you've created your own module bundle repo, you can even create a bash alias for this and accellerate the process even more: alias getpwstartmodules='cd site/modules && git clone --recursive git@github.com:marcus-herrmann/ProcessWire-BootstrapModuleSet.git && cd ProcessWire-BootstrapModuleSet && git pull --recurse-submodules' I possibly may have reinvented the wheel. But at least I haven't yet found such a way for "PW kickstarting" before (apart from maybe pure bred package managers such as npm and composer). But if a better solution exists, please do not hesitate to drop a comment here Disclaimer: This is also a blog post

Thank you very for the starting point. Unfortunately, prepopulation of the roles seems not to work. At first, I removed owzim's config helper again since I will care about config defaults later. Then I did the following: public function __construct() { $this->allowedRoles = array(); } public static function getModuleConfigInputfields(array $data) { $wrapper = new InputfieldWrapper; $f = wire('modules')->get("InputfieldAsmSelect"); $f->required = true; $f->attr('name', 'allowedRoles'); $f->label = __('User roles allowed to flag'); $f->setAsmSelectOption('sortable', false); if(isset($data['allowedRoles'])) $f->value = $data['allowedRoles']; // populate with all available roles foreach(wire('roles') as $roleoption) { $f->addOption($roleoption->name); } $wrapper->add($f); } But in the module's settings I get the warning: Warning: Invalid argument supplied for foreach() in /sites/processwire/flagpages/wire/modules/Process/ProcessModule/ProcessModule.module on line 730 So wire('roles') is not available in the getModuleConfigInputfields method? Hard to believe, since wire('modules') is :-/

That's what I am aiming for, but I'm not quite sure how to do it (sure - using $this->modules->get("InputfieldAsmSelect") - but then, no idea, really). Frankly speaking I'm not sure if even the comparison of allowed roles array vs. current user roles array is done elegantly. It works, though. Since this is my first module, I wanted to take only tiny steps forward But if anyone point me to the right direction I would be very thankful.

Just released version 0.2.0 and added setting to limit flagging ability to certain user roles