Robin S

That sounds like an issue that should perhaps be fixed in the core - when redirecting due to lack of access I don't think this should be permanent redirect because as you say the user may just need to log in and then they should have access. Maybe you can create a GitHub issue for this to get Ryan's take?

The actual action I noticed this on works with an external database so it's not easily shareable but attached is a demo action that shows the issue. Thanks for taking a look at this. DemoAction.action.php

Hi @adrian, Within an admin action we have the option to return true or false depending on if the action succeeded or failed (and I assume success or failure is up to the action author depending on what the overall objective of the action is). If an action returns true then a database restore link is shown. But it seems that if the action returns false then the link to restore the database is not shown. I'm not sure if no backup is made or it's just the restore link that's missing - maybe the former because when I manually visited the /restore/ URL segment and clicked the Restore button then the restore didn't work. Is it possible to get a backup and a link to restore it when an action returns false? Also, maybe the background colour of the failure message could be a pale red because it's hard to see links against the dark red (there's actually a link to the logs in the failure message above). BTW, the module readme doesn't make it entirely clear that an action should return false on the fail state, as only the failureMessage is mentioned:

I think you might be working with the wrong init.php - you'll see in my earlier post that the hook needs to go in /site/init.php. Along with /site/ready.php this is one of the places that hook code is commonly added to. You can create either/both of these files if they don't exist. More info in this blog post: https://processwire.com/blog/posts/processwire-2.6.7-core-updates-and-more/#new-core-files-for-site-hooks Turn off ProCache while you are investigating the issue to make sure it isn't contributing to the problem.

@gerritvanaaken, I created a module in response to your topic:

A module created in response to the topic here: Page List Select Multiple Quickly Modifies PageListSelectMultiple to allow you to select multiple pages without the tree closing every time you select a page. The screencast says it all: https://github.com/Toutouwai/PageListSelectMultipleQuickly https://modules.processwire.com/modules/page-list-select-multiple-quickly/

@Ben Sayers, you can use bd() to dump the $url variable in the hook. $wire->addHookBefore('ProcessPageView::pageNotFound', function(HookEvent $event) { $url = $event->arguments(1); // Dump $url to the Tracy debug bar bd($url, 'url'); // The old URLs you want to redirect from (relative to site root) $redirects = [ '/blog/foo/', '/blog/bar/', ]; if(in_array($url, $redirects)) { // Get the blog landing page however suits $blog_page = $this->wire('pages')->get('template=blog'); // Redirect to blog landing page $this->wire('session')->redirect($blog_page->url); } }); When you visit a URL that does not match any page then you'll see the $url variable dumped via the Tracy debug bar. Tracy docs are here: https://adrianbj.github.io/TracyDebugger/#/debug-methods?id=bardump Enter some random letters in the URL to confirm that the hook is firing and you can see the dump. Then try one of your old blog post URLs. If you don't see any dump then the hook is not firing, in this case because ProcessPageView::pageNotFound() is not executing. In which case you have something interfering before PW can attempt to render the page requested in the URL - so probably due to an .htaccess rewrite or something caused by Jumplinks (or another module or hook if you have anything else that affects URLs).

Super-cool, thanks!

I'd be totally fine with that. It could be a "Don't create field" checkbox and you could even use some custom CSS to put it somewhere subtle and out-of-the-way. That way it's not distracting/confusing for people who use the module in the standard way but is available for those who want it.

That sounds sensible. I guess Pluralize would need to be reinitialised with different settings depending on if a field is being created or not, so you could put that JS into a function with a parameter that switches the type of initialisation and then call that on window load and on checkbox change. Or there are probably other ways too.

Hi @adrian, This will probably sound like an odd request given the name of the module... What do you think about adding an option to not actually create a Page Reference field but only create the templates and pages (if any)? The smart template naming and template restriction features are so useful that I often execute the module and then just delete the Page Reference field because I don't need it. I'm not sure if you or anyone else ever do this, but if I'm not the only one maybe it would be a handy addition to the module?

Sounds like something is interfering before ProcessPageView::pageNotFound can execute. You can check by using Tracy Debugger to dump $url inside the hook and see if the hook is firing or not. If not then it might be caused be something in .htaccess or in Jumplinks. To check you could copy the site to your local machine, replace .htaccess with a clean copy and uninstall Jumplinks - whether it's worth the trouble depends on how important it is to you to get those redirects working.

I can see a few issues, mostly relating to your formatTags setting: 1. The Format plugin is for block-level elements and the <a> element you have included is not block-level. 2. Normally list formatting is applied with the dedicated <ul> and <li> buttons and not via the Format dropdown. 3. You are configuring format tags but you haven't included the Format dropdown in the toolbar, so the format tag options aren't going to be available the user. 4. If you specify format tags beyond those configured by default in CKEditor (p;h1;h2;h3;h4;h5;h6;pre;address;div) then you have to configure corresponding "format_(tagName)" settings. This is the cause of the JS error. From the documentation: 5. Usually you don't want TextformatterEntities applied to a field that is going to contain HTML. If what you are trying to do is remove the heading options from the Format dropdown then you can set Format Tags to "p" only and the NumberedList, BulletedList and PWLink toolbar settings will allow those corresponding tags also.

@Ben Sayers, if you're still having problems and just need a solution to get the redirects working you could hook ProcessPageView::pageNotFound in /site/init.php $wire->addHookBefore('ProcessPageView::pageNotFound', function(HookEvent $event) { $url = $event->arguments(1); // The old URLs you want to redirect from (relative to site root) $redirects = [ '/blog/foo/', '/blog/bar/', ]; if(in_array($url, $redirects)) { // Get the blog landing page however suits $blog_page = $this->wire('pages')->get('template=blog'); // Redirect to blog landing page $this->wire('session')->redirect($blog_page->url); } });

Check that you have given the role in question the "page-lister" permission.

You need to pass your settings to $config->js() in a renderReady() method. https://github.com/processwire/processwire/blob/7d4ca45673152436ea492b6577341ee3550e2821/wire/core/Inputfield.php#L1224-L1244

Attempt to log in via the LoginRegister module several times in short period of time using an incorrect password.

Welcome to the forums @skoskie ? The Comments fieldtype already includes a star rating option: https://processwire.com/blog/posts/processwire-2.6.21-upgrades-comments-more-on-pw-3.x/#new-star-ratings-for-comments-fields

@msavard, in this module HTML tags are not supported inside attributes. But you could use Markdown for the same result, for example: In your attribute: Claims filed between **February 16 - December 10** will receive a [partial exemption](https://www.google.com) for that year. In your Hanna Tag code: <div class="message-box"><?= $sanitizer->entitiesMarkdown($text) ?></div>

Maybe: check_access=0 https://processwire.com/docs/selectors/#access_control

Awesome, works great!

I'm sure you're right, but I'm not 100% clear on what you mean here. It seems like both include and exclude settings would use OR conditions: exclude (role1 OR role2 OR role3) include only (role1 OR role2 OR role3) Or maybe you mean AND/OR in terms of combining the two settings? "exclude (roles) AND include (roles)" versus "exclude (roles) OR include (roles)" I imagined using one setting or the other but not both, but maybe there are some situations where a user would want to combine them.

Hi @adrian, I have a little problem with the User Switcher panel: there's a config option for limiting the list of users that appear in the panel, which is great because often there can be a lot of front-end-only users. But the problem for me is that the option gets defined in terms of roles that are excluded rather than included: I'm not sure how common this is for others, but I often give back-end users (who I want to be able to switch to via the User Switcher) front-end roles because they can also be "members" as well as "administrators". So these kinds of users have multiple roles. What do you think about adding an "include only these roles" option for User Switcher as well as a "exclude these roles" option? Or maybe you have another idea of how this might be accommodated?

v0.1.10 released. Now that new core ways of setting field widths in template context have been introduced it seems that users are sometimes setting a field width using a core input and then saving the Edit Template form. Although it's not necessary to save the Edit Template form after adjusting a field width using a core input (those settings are AJAX-saved), it's not unlikely that users will do this and in these circumstances the old width stored in the Template Field Widths inputfield was overwriting the new width. So from v0.1.10 onward the widths entered into the Template Field Widths inputfield are only saved if Edit Template is saved with the Template Field Widths inputfield in a open state. And it's recommended to use the default "Collapsed" config option for Template Field Widths if you think you might also use core inputs for setting field widths.

All good if another way is added to open files in PhpStorm, but I use the editor:// protocol with PhpStorm and never had any problem with it. It's been a long time since I set it up but I expect I followed the PhpStorm docs and I don't remember it being difficult.