adrian

Done: https://processwire.com/about/processwire-reviews/

Update to the User Dev Template functionality - it is now tied into the Template Path panel so that you can have an easy visual indicator to alert you when any user is being served an alternate template. Before I explain further, the one breaking change from yesterday is that the system now only checks for "template-****" permissions and not roles. If you want to assign to a single user, then create a new "template-****" role and give it the "template-****" permission. In this screenshot, you can see the reminder detailing why the icon is orange. Currently we are not viewing a page with an alternate template, but it is letting us know that: the "User Dev Template" option is enabled in module settings the "template-dev" permission exists the permission has been assigned to at least one user there are template files with a "-dev" suffix So if this is expected then great, but if not, then you can prevent the alternate templates from being rendered by doing one or more of the following: disabling the "User Dev Template" option removing the template-dev permission from the system remove the template-dev permission from all roles delete alternate template files with the "-dev" suffix If you are on a page that is using an alternate template due to user permissions, then you will see the PW permission cog icon: I hope this visual indicator will make this functionality easier for you to manage.

Another nice little (but hopefully useful) addition for you guys! This is not a panel, but it is in the same vane as the Template Path and Template Editor panels. This makes it really easy to show authorized users development versions of template files. To make this work, all you need to do is enable the checkbox. Then setup either a "template-dev" role or permission and assign that to the required users. Obviously this is not the best approach for major changes (you should set up a dev subdomain for that), but I think it could be quite handy for certain site changes. While you should keep track of any roles/permissions you have assigned, you can quickly disable this functionality by unchecking the enable option, or by deleting the template files (because if the dev version isn't available, it will fallback to the default one). Let me know what you think - I am happy to modify how this works if anyone has any suggestions. PS - yes I know you don't need a module to do this - a couple of lines in your ready.php file would also take care of it, but for some users I think this is simpler and easier to manage. PPS If you decide to go the route of using a permission (rather than a role), then you might find this type of selector on the Users page useful so you can see which users have the "template-****" permission.

Have a read of this post: It should explain everything you need.

What you want is this: $matches = $pages->find($selector); $the_page_array = new PageArray(); foreach($matches as $match) { if ($match==condition_blah_blah) { $the_page_array->add($match); }

You could also make use of this module: http://modules.processwire.com/modules/process-redirect-ids/

Hi @wet - based on the line number (120) shown for ProcesswireInfoPanel.inc it looks like it might be related to getting the previous page. I am wondering if maybe this is no longer a problem since: https://processwire.com/blog/posts/pw-3.0.24/ Could you please provide an update so I know if I still need to fix something in Tracy or not. If it is still a problem could you please confirm that it goes away if you disable the PW Info panel?

No problem - one final thing though - why do you have underscores rather than dashes in your page names?

I don't see where you are defining the $target in: $targetPage = "color_items_".$target; Also, keep in mind that "/color_items_desktop/" is not exactly the same as "color_items_desktop" which is what I am expecting you are ending up with.

Firstly, be very careful with user supplied data in a selector string - you need to sanitize it. Also, it would be helpful to know what you are wanting the selector to be. I can't really see how "site-" at the beginning of any selector would be what you want. You should definitely read that link that @LostKobrakai noted. Most likely you are wanting to use a page path, but it's impossible for us to know based on your example.

Glad you are finding those modules so useful - especially the page select creator - it is definitely a time saver - it can be a little time consuming and confusing to get the template parent/child permissions correct.

No problem - actually, you don't want to modify the wire/config.php - you just use that as a reference and copy any options you want from it to the site/config.php and modify as required. BatchChildEditor module is also helpful if you need to make changes to lots of child pages at once. EDIT: Beaten by @fbg13

Check out advanced mode in config.php and you'll have this for each template: Maybe doesn't take care of everything you need, but remember that the status can also be changed from the Page List view via the extended (after the arrow) action buttons.

I have committed some significant updates to the Mail and Event Interceptor panels over the last couple of days. Both now store the data they have captured in a session variable so new items captured will be added to the list in the panel. This also removes the need prevent redirects in the code just to see the data. @tpr has been a great help in debugging several things - thank you! I think the Mail panel is now working very reliably and should prove a great help in testing/debugging form emails and the like. The Event Interceptor appears to be working fine, but I have noticed that it can be quite destructive if you're not careful - one example I noticed when I had the Pages::save hook setup in the admin was that some pages ended up having the trashed status, but their parent was still listed as "1" (ie the home page). I still like the power this panel offers - especially when you want to prevent the creation of new pages when submitting test forms, but I am wondering whether it should be limited to front-end API actions only (to reduce possible damage), or whether it might be useful to have a "Capture Only" option which means that it won't prevent the event, but will simply capture the object and arguments to display in the panel. I need to think through this a little more, but would also really appreciate any thoughts from those of you who have tried it out.

The path to those is still incorrect - you are calling them from: http://www.casbook.org/site/templates/js/init.js and you are linking to: css/style-wide.css That means that the browser is trying to load: http://www.casbook.org/site/templates/js/css/style-wide.css because the css folder is relative to the js folder where the init.js file is. There are lots of options to make this work so I can't give you a definitive approach, but you could simply replace: css/style-wide.css with /site/templates/css/style-wide.css

Thank you Ryan - this is going to be amazing!

The paths to your css files are not correct: http://www.casbook.org/site/templates/TFhome1-assetto/js/init.js See for example the link to: css/style-wide.css

Due to variable scoping in PHP, PW variables (like $page) are not available inside functions. You need to use: wire('page') instead.

There might be something to this - I actually hook into session::redirect for the Event Interceptor panel for situations like this - looks like I might need it for the Mail panel as well. Yeah, that makes sense - if you're not using jQuery, you will need to manually set this or the Tracy AJAX panel won't be triggered - nothing I can do about this unfortunately, short of storing the emails in a cache so that they are available after a page refresh, but I think the AJAX bar is a nicer solution for the most part.

Sounds like that might be the easiest option - thanks. I am not sure what is going on for you - the hook is on WireMail::send (https://github.com/adrianbj/TracyDebugger/blob/master/TracyDebugger.module#L273) so it should work. I am sure if I can have access I'll be able to figure it out. Nope - the panel adds a before hook to whatever you specify, so if you type in Pages::save, it will hook whenever a page is saved (via the admin or API - I have tested both successfully), prevent it from being saved, and simply return the event to the panel so you can view what it would have done. Please try this out with your form and let me know how it goes.

Ok, the Mail Panel is now available! I have also added a new related panel called "Event Interceptor" that let's you define any Hook that you want to intercept. Much like the Mail panel, this new panel prevents the chosen hook from being executed, but instead, returns that contents of $event->object and $event->arguments in the panel instead. This may be useful for debugging all sorts of things, but my primary motivation for adding this is to prevent pages from being created when testing form submissions, by using Pages::save. Both of these panels (unlike most of the other custom ones - because there is no point, not because it's not possible) also work via AJAX calls - note that both their icons appear in the AJAX bar in the screenshot below. Note that the Mail panel will be active and intercept emails sent while it is enabled. The Event Interceptor will only work if there is a hook entered and "Set Hook" is clicked. To clear it, click "Remove Hook". Hooks need to be entered like so: Pages::save Both of these panels should be considered alpha at this stage, so please don't use on a live site just yet. Mail Panel icon colors: Green - no emails intercepted Red - at least one email intercepted Event Interceptor icon colors: Green - no hook set Orange - hook set, but nothing intercepted Red - hook set and event intercepted As I mentioned above, please consider these two panel alpha at this point, so please test carefully and give me your feedback - I expect the functionality of these to possibly change significantly based on everyone's ideas.

Hey @tpr and anyone else interested in the Mail panel. I have the first version up and running locally, but thought I would post a screenshot first to get some initial feedback before committing the code. Features: If the Mail Panel is enabled, it will intercept any outgoing emails - they won't be sent out, but instead, displayed in the panel. Each email sent gets its own entry which is great if you have one sent to the user and one back to the admin (or similar). You can toggle the body in text, html, and html source versions. Any initial thoughts on the layout or functionality?

Just change the template of the 404 page from basic-page to a dedicated 404 template and restrict editing via the template Access tab. I honestly thing PW should have a separated template for the 404 page by default.

I feel like this would be the most consistent solution - it sounds like a panel you won't need most of the time, so just activate for when you need it. I'll definitely add this to my list - the more I think about it, the more I am realizing how useful it will be.

Is that necessary - surely it would only capture sent emails when you are logged and Tracy is in Development mode (or forced development for superusers)? Maybe I am missing your point though