adrian

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?

@LimeWub - you might also find this useful: https://processwire.com/blog/posts/processwire-core-updates-2.5.14/#multiple-templates-or-parents-for-users It's lets you place your users under a different parent or with a different template.

Just stumbled across this very old topic while looking for something else and thought I should mention the Admin Restrict Branch module in case others come across this.

I know this is old, but just a follow up to mention that Tracy Debugger has a few options for achieving similar functionality. Files Editor panel lets you test changes without affecting what other users see. When ready you can push the changes live. Template Path panel lets you choose from a variety of templates with -dev, -test etc suffixes. The User Bar has a "Page Versions" component that lets authorized users choose from alternate templates (this is basically a non-superuser version of the Template Path panel. User Dev Template Options - this lets you set users with certain roles to automatically see the page with a different version of the template file. Anyway, thought some of these might be useful to others who come across this topic.

I might be easier to change the parent of the RepeaterMatrix rather than trying to move each item and their contents. This is what I did with the PageTable to Repeater converter: https://github.com/adrianbj/ProcessAdminActions/blob/bcb8479e90224f958f0747476657c459cd230307/actions/PageTableToRepeaterMatrix.action.php#L294 Not saying it is the only/best solution, but it seemed to remove the hassles of handling different fieldtypes in my situation at least.

@Soma - just wanted to let you know that I have made more changes to @owzim's script. The new version adds this functionality adds dynamically added hooks like Page::viewable which were not previously detected cleans up code within a function when it's on the same line as the function definition, eg. https://github.com/processwire/processwire/blob/35df716082b779de0e53a3fcf7996403c49c9f8a/wire/core/NullPage.php#L112 removes any comments from the returned info - previously if a comment was on the same line as the function definition it would be returned also. You can see my changes here: https://github.com/adrianbj/TracyDebugger/blob/master/panels/CaptainHook/CaptainHookSearch.php Let me know if you have any questions.

Hi all! Major overhaul / refactor just committed. To quote Github: Showing 54 changed files with 1,705 additions and 1,295 deletions. Yes, I haven't slept much lately I have tried to test everything very thoroughly, but with so many changes, there might be new bugs introduced. Please let me know if you find any issues. You'll also noticed that I have bumped the version number to 4.0.0 and am using a string now so that I can start being more semantic with the version numbers. Here's a rough highlight of the changes. New skin - a huge thanks to @tpr for all his efforts on this, not to mention lots of other feedback / bug reports while developing this new version! Captain Hook Improvements - it now shows dynamically added hooks, like Page::viewable in both the core and your site module. Also some general cleanup. More SessionHandlerDB fixes - there were still some outstanding issues with some of the lesser used panels. Hopefully we're closer to this being a non-issue. Improved CSS loading - in particular when opening panels in a popup window. General code updates - various things, including updating wire() and $this calls to $this->wire() where appropriate. Lots of bug fixes - mostly issues with the lesser used panels that had gone unnoticed, but still it's amazing what you find when you do a major refactor. Better code documentation - not my strong point in the past - hopefully this is now on the way to being much better. File / folder restructuring - not really of concern to you guys, but will make life a little easier for me going forward with future enhancements. Captain Hook panel showing new dynamic hookable methods and @tpr's fantastic new skin!

But what file were those line in?

How exactly did you solve it? I'd like to know why those other lines were there in the first place.

If you are trying to get to 3.0.42, then there should be no need to bother with 2.8 (it's a legacy version). I would go straight from 2.7 to 3.0.42.