adrian

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

Done! Makes sense - let me take a better look at that existing panel. Unfortunately most of the existing Tracy plugin panels require the entire Nette framework, so it is unlikely I will be able to use that one directly. I initially started with someone else's ToDo panel, but even after I had stripped out all the requirements for other Nette components, I still didn't like the way it was parsing out comments, so I ended up writing a new one from scratch I guess I am not totally sure how this would help. At the moment by default, it only scans files inside /site/templates. With that new checkbox, you can now expand this to include /site/modules, but I doubt many will want to add this option. I am think most will want to scan all of /site/templates, but simply exclude some parent folder like /site/templates/scripts/libraries/ where they would add all third party js libraries. Can you explain what folders you might want to exclude that a regex could help with - that would help me better understand how to implement. I am not totally sure on this either - you'll notice when you have Tracy enabled in the backend, there is an additional bar that shows up when the admin makes ajax calls (like for getting menu subitems), so theoretically I could have an "email" panel also show on the ajax bar - currently I disable all of the custom panel (except performance) from appearing on the ajax panel, but I can make an exception for an email one. I am guessing this shouldn't be too hard - just need to hook into wireMail. Perhaps you guys ( @tpr and @bernhard ) could come up with a list of required features?

I guess I am a little confused about the purpose - the https://github.com/nextras/mail-panel seems to capture outgoing messages sent from the server, but https://mailcatcher.me/ seems to display messages sent to a particular email address in a web interface. What functionality are you actually looking for? Maybe if I know more I'll have a better idea about whether I think it should be in Tracy or not.

Don't apologize - feedback is what I need Yeah, good point about modules - I think it makes sense to have the option to scan the modules directory too - I don't recommend this for most users as it can slow things down a bit, but the latest version now includes a config settings checkbox to allow this if you want. I also fixed the error if you empty the ignore dir list as well as improving some other elements of comment parsing.

if(!$pages->get("name={$item_id}")->id) { // create new page } Although you probably want to add other limiters to the selector, like a parent page or template.

@Macrura - just to follow up, I have committed that change - now when you save the module config settings in the backend, the list of panels is reset to the permanent list in those config settings - ie, the Sticky list of panels is Reset. Hope that helps to avoid confusion / problems for others also.

That's not the behavior - sticky changes to the panels are stored in a session cookie. Maybe that is confusing, but it was designed to be a way to have panels display temporarily, but for more than one page reload. Maybe what I need to do is have saving the module config settings clear that session cookie (same as clicking "reset" in the selector panel on the frontend) - that seems like a logical solution to me - I'll implement that now. No problem - let me know if there are any changes that would help with your use case.

From my experience, @Robin S's solution is definitely the way to go!

Sorry it is proving slow for some (maybe all of you guys). Wish I was seeing the problems here so I could debug. Does anyone have a live server that is running slow that they'd be willing to give me access to so I can take a look? I'd really like to get this sorted out so no-one feels the need to have an on/off toggle. Are any of you running xdebug? Does disabling it completely make a difference?

I was hoping that was the issue - it certainly loads very quickly for me here. If you ever do find some time to investigate where the problem might be, I'd appreciate it.