adrian

Hi @tpr - I have made all those requested changes and also several other updates to the module. Please let me know if you find any problems.

You can also avoid recursive issues with hooks on save by just saving the field you have changed, rather than the entire page, eg. $OtherPage->save('ThemeCachedCSS');

Ok gotcha - I see how it helps now. I had a quick look and couldn't figure out what it achieved, but now I see and agree it's a little nicer. I wish there was a way to not have it partly cover the sidebar, but with those elements being absolutely positioned, I don't see an option. I think what I ended up with is a decent compromise though - it's narrow enough that it doesn't interfere, but is still obvious enough. If anyone has any better ideas I'd be happy to change.

Hey @tpr - where do you think this should be applied? Sorry if I am missing the obvious

I know it doesn't help much, but I am using the update module with PHP 7.1 with no problems. I know there were some issues with early versions of PW 3. Have you tried upgrading to the latest dev?

PW won't let you call php files directly from the sites directory (including the templates subfolder). You can either put the load.php into a folder above sites, or you could assign the file as a template for a page and load("the_page_url");

yep: /** * Installer: Database Configuration * */ $config->dbHost = 'localhost'; $config->dbName = 'pwtest'; $config->dbUser = 'root'; $config->dbPass = ''; $config->dbPort = '3306';

Well given that PHP can't determine the screen width, you'd have to get it via JS and then do an AJAX call based on that width. Honestly I don't think there is much point to that. Just get as many posts as you need for the widest screens and then limit their display with css or js.

Let's take this to PM

Hi everyone! Introducing the new Style Admin by Server Type feature. Hopefully this will reduce the chance of accidentally editing the wrong version of a site when you have more than one open in different tabs. Firstly, a huge shoutout to @szabesz for the idea for this new feature and for lots of testing and suggestions to improve it. Also @tpr chipped in with some CSS help yet again! This feature adds a ribbon down the side of the admin to let you know what version of the site you are on, eg. local, dev, staging, etc. Firstly you will need to enable it in the config settings. Then you'll want to set up your various server types and colors. It comes with the following defaults. If you don't like the side ribbon, you can actually style the output exactly how you want.

@johnteaksf - I have personally used it many times with AngularJS and plan on using it for the first time with VueJS pretty soon. A couple of other resources that might be helpful: https://processwire.com/blog/posts/roadmap-2017/#whats-in-store-for-processwire-in-2017

No problem - thanks and sorry for the problems in the first place! Just an FYI why this is happening. It turns out that I had to move lots of logic from ready() into init() to fix some more SessionHandlerDB issues. The problem is that $input seems to be available much earlier in PW 3 than it was in PW 2, hence the reporting of $input as null.

Thanks. Can you please try replacing lines 227 and 228 of TracyDebugger.module: // don't init Tracy for the PW Notifications module polling if(strpos($this->wire('input')->queryString(), 'Notifications=update') !== false) return; with: // don't init Tracy for the PW Notifications module polling if($this->wire('input')) { $queryString = $this->wire('input')->queryString(); } else { $info = parse_url($_SERVER['REQUEST_URI']); $queryString = $info['query']; } if(strpos($queryString, 'Notifications=update') !== false) return;

Do you have the very latest version of Tracy - that PW 2.x problem was reported already and I fixed in in 4.0.1, unless it is occurring for some other reason as well.

Nice one - I totally forgot about this

I think password fields are required regardless of whether the "required" checkbox is checked or not. You'll notice that the system "pass" field doesn't have required checked. You should be able to get around this though with this in your admin.php $this->wire()->addHookBefore('InputfieldPassword::processInput', null, function($event) { $event->object->required = false; }); You will probably want to limit it to your custom password field though, rather than all password fields.

Of course Absolutely Now the question is whether it should just be local vs live (detected by IP address), or whether it also needs to include subdomain detection so you can color by dev.mysite.com vs staging.mysite.com vs mysite.com. Any thoughts?

@tires - this could actually be a nice AdminActions action. I would use the "Template Fields Batcher" action as a starting point as it will show you how to add fields to templates. If you like this idea and have a go at building an action, please let me know if you need any help.

I was wondering about both of these. I actually always have Tracy on in the backend (especially now that we have the "Reference page being edited" option), but I understand that not everyone will. I could pretty easily color the masthead in the backend, eg: It can start looking pretty ugly but I guess since it's only for superusers (and other authorized Tracy users) it doesn't really matter ?

Just been playing around with a quick visual indicator to let you know if you are on the local or live version of a site. It's done by IP address using the same code that Tracy uses for its DETECT module to switch between DEV and PRODUCTION. Not sure how useful this is, but I do know that I sometimes have the local and live versions of a site open in separate browser tabs and occasionally I'll accidentally edit content in the wrong one. I am usually very careful, but we all make mistakes and just thought this might help as an additional visual indicator (without having to look at the address bar). Of course it could be taken further with customizable colors and customizable ways of defining what is dev vs staging vs production if they are all on live servers. Any thoughts on whether you guys would make use of this? Local Live

I have just added a "Config" section to the Debug Mode panel. This returns a nicely formatted table of all the properties of $config - this includes those set in /wire/config.php and /site/config.php, as well as many other derived system settings. To make this visible you will either need to add 'config' to the $config->debugTools array in /site/config.php, or uncheck "Respect the PW $config->debugTools config option" in the Tracy config settings. It shows way too many things to list here, but I think it makes a nice additional resource, so please be sure to check it out. Of course all arrays are expandable.

Or @kongondo's menu builder: http://modules.processwire.com/modules/process-menu-builder/

Can't you go back to the official released version? Honestly I don't plan on spending too much time on this module - I don't think it gets much use. I created that new version for you to support url segments, but now it seems that you don't want them? Maybe I don't fully understand your needs. If you could give me a full explanation of all the scenarios you want supported I can take another go at it.

I guess I am not sure what the problem with the render approach is then. You say you want a 200 header. Can you add this before render() header("HTTP/1.1 200 OK"); I don't know what the incompatibility with the MarkupSEO module is, but maybe you can workaround it by setting the priority of your hook. See an example in my 404Search module: https://github.com/adrianbj/Process404Search/blob/4d9bd7a773d14bc29524c0798ad500050d969685/Process404Search.module#L58

Maybe I am not fully understanding, but it sounds like maybe you just want a $session->redirect($p->url). Although be aware of redirecting 404's to valid pages in general - are you limiting this to certain pages for a specific reason?