Robin S

@PWaddict, if I understand right you want to set a limit of zero items. I added support for this in v0.1.6.

@dragan, I just pushed an update to the repo (no version number change) that adds the "Source" button to the CKEditor field to make it easier to check/report any issues with source code.

@dragan, everything seems to be working normally for me. If you can paste some CKE source code from a list that is causing you problems I'll investigate.

@dragan, my previous commit to v0.1.4 contained a silly mistake that didn't account for nested lists. Should be fixed now in v0.1.5.

@Ivan Gretsky, this issue should be fixed in v0.1.4.

Cool, will update. Something unrelated I'll just throw out there for the wishlist... it would be cool if the code window in the Console didn't resize proportionally when the panel is resized. So the code window would have a pixel height rather than a percentage height and the result window would have a height along the lines calc(100% - [console window pixel height]). I know you added a lot of neat stuff relating to the code window height (line snapping and keyboard shortcuts) and for all I know this request would complicate all of that, in which case don't worry because it's not that important. ?

Thanks, working well for me as guest/non-superuser on localhost, and when using User Switcher on remote host.

Okay with me as I do almost all development on localhost.

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