Robin S

Thanks for adding this feature! There seems to be a problem with the console output though. No matter what I dump the output consists of the entire rendered page. This occurs when using the console as guest or logged-in non-superuser.

@bernhard, thanks for the pull request. I've merged parts of that along with a few more of my own changes. But probably not necessary to do much more with this particular repo though because it really only exists to serve as a quick demo for people like yourself who might like to take the idea further. I'm not feeling possessive of this idea/code at all so anyone is very welcome to take it and use it for their own purposes in any way they like - further developments don't need to happen via my repo. To go further into something that would be more widely useful to the community, shared in the modules directory, etc, would require a new module that doesn't bundle any particular Process module like my demo does. I'm imagining something that would work with any custom Process module. And maybe focuses on the iframe approach because that seems the most promising (I was also playing around last night with the same JS library you mentioned). I might tinker around with something later but anyone is welcome to have at it and beat me to it. ? To respond to some of your points... Great, we don't want that exposed. I wish there was a better way than string replacement on the whole HTML output but there isn't any way I can see to set that part of the JS config object directly and I fear setting $config->urls->admin before the page render could have other unwanted consequences. The redirect isn't really about the ?modal=1 (although that is unwanted) - it's the Post/Redirect/Get pattern. If you look at the core Process modules you'll see that they all redirect after form POST submissions. In any case the specific code within the demo Process module is not something that anyone needs to use, it's just so the demo module renders something visible. What a person puts in their execute methods will depend on what they want their module to do. Incidentally, setting $this->wire('input')->get->modal = 0 unfortunately doesn't solve the problem for redirects as these still have the modal parameter forced onto them. I think the simplest solution for that is just to make sure any redirect URLs include "//" (e.g. use http URLs). I think it is too late within any Process module to throw a 404 exception. The best I could come up with is to check that any URL segment is valid and if not redirect to the 404 page. Maybe someone will discover a better way. Thanks to this post I think I have a solution for this, added in the recent commit. ProCache can run on any page where the user isn't logged in, which for guests will be all pages besides the ones executing a front-end Process module.

The HTML for these elements is not rendered at all - in AdminThemeUikit at least. See $layout == 'modal' and $adminTheme->isModal here. It's a way of calling protected class methods from hooks. See here.

Hi @bernhard, I did some experimentation with an alternative idea for viewing Process modules on the frontend. I put together a proof-of-concept module you might like to check out: https://github.com/Toutouwai/ProcessFrontendAdminPage Process Frontend Admin Page A demonstration of how a Process module could execute on the frontend. This is just a proof-of-concept. Usage Install the ProcessFrontendAdminPage module. Create a new role named "frontend-only". Give this role the "process-frontend-admin-page" permission and no other permissions. Create a new user named "frontend-only" and give them the "frontend-only" role. View the "Demo frontend admin page" on the frontend while not logged into the PW admin. How the module works On install the module creates a "Demo frontend admin page" under Home. This page uses the admin template with the ProcessFrontendAdminPage process assigned. When this page is viewed by a guest they are silently logged as the "frontend-only" user. This allows them to see the rendered output of the Process module. The header and footer of the admin theme are not rendered when the page is viewed. When a user logged into the "frontend-only" account accesses any other page they are logged out. This is for the sake of logged-out users of other roles, so that when they go to log into the PW admin they don't find themselves already logged in as the "frontend-only" user. Taking the concept further You could embed the ProcessFrontendAdminPage output in an iframe on another page, to preserve a global header/footer and avoid conflicts with the admin CSS. You could add extra markup, Javascript and CSS to the ProcessFrontendAdminPage output to make it look more like the rest of your site. You could create additional executeSomething() methods to render different output depending on URL segment. You could create additional pages within your site that use the admin template and assign the ProcessFrontendAdminPage process. I think you would have to use API code to do this. Then in the execute() method you could check the name of the page being viewed and render different output accordingly.

It's strange that the location of the 404 page would affect the trash. An alternative way to hide the 404 page instead of moving it is to hook Page::listable() $wire->addHookAfter('Page::listable', function(HookEvent $event) { if($this->wire('user')->isSuperuser()) return; $page = $event->object; if($page->id === 27) $event->return = false; }); I actually like to go a bit further than this, and say that if a page is in the top level and is hidden and the user doesn't have edit access for the page then it is of no concern to them and they don't need to see it in Page List: $wire->addHookAfter('Page::listable', function(HookEvent $event) { if($this->wire('user')->isSuperuser()) return; $page = $event->object; if($page->parent->id === 1 && $page->isHidden && !$page->editable) $event->return = false; }); In my case I give the 404 page a dedicated template that non-superusers do not have edit access for, and so it is hidden in Page List.

That sounds like a reasonable way to return early if the form is not the one you are wanting to modify. Any problems if you do that?

Not sure sorry, but it's working for me:

If you include a TwilioChannelsConfig.php file with your TwilioChannels module (see the blog post that introduced this approach), this file is only for defining the config fields for the module. It isn't a module in its own right that you can get with $module = $modules->get('TwilioChannelsConfig'). Put all your methods - including your hi() method - into the main TwilioChannels module file. $module = $modules->get('TwilioChannels'); echo "<p>" . $module->hi() . "</p>";

It looks like there are many settings that can be defined for InputfieldSelector, but only initValue can be set via the FieldtypeSelector field config. For the others you have to use a hook. The previewColumns setting controls the columns shown: $wire->addHookBefore('InputfieldSelector::render', function(HookEvent $event) { /* @var InputfieldSelector $inputfield */ $inputfield = $event->object; // Only for the FieldtypeSelector field of the given name if($inputfield->hasField != 'test_selector') return; // Define the columns you want $inputfield->previewColumns = ['name', 'template', 'modified']; });

@adrian, did you notice this snippet from Ryan in the issues repo? if(!isset($_SERVER['HTTP_HOST'])) { // likely running in CLI mode $config->httpHost = 'examplesite.ru'; } else if(preg_match('/^[a-z]{3,20}\.examplesite\.ru$/i', $_SERVER['HTTP_HOST'])) { // host name matches abc.examplesite.ru where abc is between 3 to 20 a-z characters $config->httpHost = strtolower($_SERVER['HTTP_HOST']); } else { // fallback if host does not match expected regex $config->httpHost = 'examplesite.ru'; } That first conditional looks like it could be a solution for your scenario.

What sort of field is "reference"? What sort of data is $selectedProduct? If that is so then it indicates that the data held in $selectedProduct is not the same as the data in your hardcoded string. Tracy Debugger is your friend here... $trialsPage = wire("pages")->get(28422); // Get the page $trialsPage->of(false); $newTrial = $ordersPage->trial_repeater_orders->getNewItem(); // Add item to repeater foreach ($selectedProducts as $selectedProduct){ // See what is in $selectedProduct bd($selectedProduct, 'selectedProduct'); $productPage = $pages->get("template=product, reference=$selectedProduct"); // Check that $productPage is not a NullPage (i.e. no matching page found) // and that is the right kind of page (template, parent, etc) to add to trial_selected_products bd($productPage, 'productPage'); $newTrial->trial_selected_products->add($productPage); } $newTrial->save(); $trialsPage->save();

@MrSnoozles, could you please clarify exactly which bookmarks you are referring to? They are used in several different modules but I'm not sure which of them could be considered clutter. Lister (Find) bookmarks - these are really useful for devs who haven't purchased Lister Pro Page Add bookmarks - the config link for this isn't visible to non-superusers Page Edit bookmarks - these can already be disabled in the config of ProcessPageEdit, and are disabled by default

This kind of selector is working for me with superuser and non-superuser roles. Did you type the "check_access=0" into the selector string by hand or did you copy/paste from @adrian's post? Because I'm seeing non-printable characters when pasting from the post: @Pete, this non-printable character issue is getting quite bad in the forums lately and can cause a lot of confusion. I don't understand how these characters are creeping into posts seeing as I'm sure nobody is entering them deliberately. Do you know if anything can be done to avoid this issue?

Thanks, I could reproduce that. Should be fixed in v0.2.3.

Thanks, added in v0.1.18 I understand your thinking here, but I think it's clearest if Breadcrumb Dropdowns keeps to the conventions of the page labels in Page List as much as possible, and Page List falls back to the page name without adding square brackets.

In v0.1.17 I call the label method so hooks are not triggered - please update and report back if you're still experiencing issues.

I added support for this in v0.1.16

You cannot use a Repeater field in a Process module. I think a similar restriction might apply to PageTable fields. It sound like your Process module is getting fields from another page, so maybe it would be better to simply edit that page in Page Edit? If you want a menu item to appear in the Setup menu you could create a Process module that redirects to Page Edit for a particular page, as @PWaddict shows in the post below:

There is discussion on this topic here: https://github.com/processwire/processwire-issues/issues/22

From the documentation for "Name format for children": So if you want date format "U" you would enter that along with at least one non-alphanumeric character - e.g. "/U" or "U/". Do not enter "date()" anywhere in the format. ProcessSetupPageName is not the same as the core "Name format for children" feature and it has different format requirements.

Very nice, thanks for the module! I have to say though, the fact that the fields get automatically added to all templates doesn't sit quite right with me. People probably only need to use time limits for specific templates and for the other templates the fields become a kind of clutter. Better I think to let people add the fields to only the templates they need to be on. I haven't looked closely but perhaps you could reduce the number of needed fields to two - just the Datetime fields. Instead of the checkboxes you can have the Datetime fields set to collapse when empty. Don't have the fields default to "today" but just let people populate them when they want them to be active and leave them empty if they want them deactivated. Another possibility if you want to make it easy for people to add/remove the fields from templates would be to have an AsmSelect field in the module config for choosing templates. Then you could hook Modules::saveConfig to get the selected templates and programmatically add/remove the fields from those templates. Clauses could be added to the selector to check... 1. Either releasetime_start is unpopulated or releasetime_start is less than "now" ...and... 2. Either releasetime_end is unpopulated or releasetime_end is greater than "now"... $pages->find("or1=(releasetime_start=''), or1=(releasetime_start<now), or2=(releasetime_end=''), or2=(releasetime_end>now)"); But rather than try and do this automatically in a hook to Pages::find (which would almost certainly be problematic) I suggest just explaining this in the documentation and letting people add it to their selectors as needed.

I'd be keen to have an option to enable the Console for non-superusers on localhost. If it's limited to localhost then there's not really a security risk I think. It would be handy for checking things like $page->addable(), $page->publishable(), etc from the perspective of a non-superuser role. When testing I typically keep an incognito window open with an editor role logged in rather than work with the User Switcher.

I'm talking about the array keys, not the values. If you use a string as an array key the string has to be in quotes or else it is interpreted as a constant. In the FieldtypeText example you show the keys are correctly within quotes. I recommend installing Tracy Debugger - it is good at picking up errors that can otherwise be missed.

Thanks for the updates! I spotted a few little issues in InputfieldTagify... There are quotes missing around version, autoload and singular in getModuleInfo(): https://github.com/Sebi2020/InputfieldTagify/blob/354acf86ac88baa8c257523cd093ec202c573fe0/InputfieldTagify.module#L18-L20 PHP gives a warning that InputfieldTagify::renderReady() and InputfieldTagify::___processInput() should be compatible with the methods of the Inputfield class that the module extends. So for renderReady() I think you want: public function renderReady(Inputfield $parent = null, $renderValueMode = false) { $this->addClass("tagify-input"); return parent::renderReady($parent, $renderValueMode); } And for ___processInput(): public function ___processInput(WireInputData $input) { //...

Ha ha, you might have spoken too soon. ? I knew that as soon as I posted this a much simpler solution would present itself. You don't need to exclude anything to make an exact match - you just need to match all the pages and the count of the pages. So no helper method is needed really. $matches = $pages->find("template=traveller, countries=Albania, countries=Andorra, countries.count=2"); Or for a more complex match where the count isn't immediately obvious: $value = $pages->find('template=country, title=Albania|Andorra'); // imagine a more complex value than this $selector = $value->each('countries={id}, '); $selector .= "countries.count=$value->count, template=traveller"; $matches = $pages->find($selector);