adrian

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.

Hi @DZuz14 - welcome to the wonderful world of PW, the anti WP CkEditor is built in to PW - you just need to choose CkEditor here from the Inputfield Type on the Details tab of your textarea field. Hope that helps!

@blynx - FYI that is because of the way you have declared the version number: 033 Either use: 33 or '0.3.3'

Isn't this a good use of @kongondo's Matrix fieldtype ?

Yeah, I am not surprised those links don't work in the version of the module I posted for you - it is looking for url segments that don't exist. This is why I need to make looking for segments optional. As for the actual Shortlinks tab - I think it's probably time I got rid of that - I don't really think it serves a purpose - any thoughts?

No problem - don't forget to watch out for upgrades to the module Btw, another approach to I think what you are looking for: Currently it only works when the children and direct child pages, but it would be easy to customize to a different branch parent. Maybe you prefer the approach you have and I think I agree with you for your use case, but this is just another option, maybe for a different project.

That shouldn't be hard, but what about just hiding the Children tab altogether using this module: http://modules.processwire.com/modules/restrict-tab-view/

@Tyssen - I definitely agree with @fbg13 here - it looks like @flydev is doing an awesome job with his upcoming module. I would hold out for that, rather than fixing an old module with much less functionality.

Maybe you should do a full mysqldump and do a search/replace in your code editor and import everything back in - should be much quicker given all those variations.

Nice work Or you could try out the new version of the module which adds support in the config settings for restricting by template(s)