adrian

@bernhard - thanks for those details - is there any chance I could get access to that live server? There is obviously something similar between your local dev and the live server if both are getting slowdowns like that. These are the times I am seeing for those tracy files so there has to be something weird and presumably fixable.

Fair enough - I don't honestly change the settings very often at all so I didn't think it was a big deal. I don't honestly think it's worth hacking on something to remember the state of a fieldset after saving (although I do think it would be a nice core addition). For the moment I have set all fieldsets/sections to be open by default. I think just having the fieldsets defined really helps to categorize the settings anyway. I have made those tweaks the s/KB items - thanks. I have also just added a couple of other new things that continue to improve page load speed. Debug panel now by default respects the $config->debugTools setting. You can configure this to show all regardless of the setting if you wish. This has the potential to speed this panel up significantly if you don't display all the tools. Button to "Delete Logs" on the the Tracy Logs panel. This panel can start getting quite slow if you send lots of PW objects to the log files, so this provides a quick/easy way to delete them all and get the panel running fast again. With the changes from the last couple of days, using the defaults that are set when installing Tracy, I am seeing a less than a 100ms increase in page load time with vs without Tracy enabled. I am pretty happy that it's now running really fast and shouldn't be noticeable. If anyone is still having significant slowdows, please try it without SessionHandlerDB installed and also completely disable xdebug and let me know if that makes a difference - thanks!

Hi everyone, I just committed a fairly significant update to the config settings allowing you to have much finer control over the content of many of the panels. I have initially focused on those panels that can have high performance hits: ProcessWire Info, Variables, & Diagnostics, so be sure to check out the options in those new sections. I have set the defaults for best performance so in general I would recommend leaving as is. Please let me know if those of you experiencing slow load times find that these new changes improve the speed. @szabesz - you know have the option to turn the Page, Template, & Field Objects back on in the PW Info Panel. I have also done an overhaul on the Variables panel - now by default it expands all variables set to PW Objects into arrays of values, using PW's getArray(). Not only is this a huge byte saving (in my test example from 950KB down to 17KB), but it is also much nicer to read. If you need the full object output back, it is a config option. The Diagnostics panel now by default only shows the Folder permissions. The File permissions and MySQL settings are disabled. You may want to change this if you generally have this panel disabled anyway and only temporarily enable it now and then. But at least now the new default setup loads very quickly if you do happen to want it enabled all the time. Please let me know if you have any problems with this new version or if you have any ideas for other config settings you'd like to have.

Now add a label to the "blog-entry" template so that it reads "Blog Entry" or "Blog Post" or whatever you want.

True - see I can't even get my only language correct I have played a little with it, but never had a need to actually use it so just wanted clarification from you to save me a little time.

Thanks for the report soma - I really have played with ML much at all - can you give me a quick rundown of what BCE needs to do to make this work as needed?

Thanks again my style guru - that is definitely an improvement - it was looking pretty messy and hard to read the panel names. Sorry about that! I'll look into making it configurable. I actually think it is time to split the config settings into collapsed fieldsets - it's becoming a bit unwieldy, so I will do this which will also make it easier to add some more panel-specific config options which I think will also be useful.

I think you are talking about changing the breadcrumbs in the PW admin - if so, then you can either hook after Process::breadcrumb, or hook before ProcessPageEdit::execute. Both have advantages and disadvantages. You can see how I did this here using the Process::breadcrumb hook. This works with both the default and Reno admin themes. https://github.com/adrianbj/AdminRestrictBranch/blob/master/AdminRestrictBranch.module#L121 Here is the the ProcessPageEdit::execute approach which doesn't work fully with Reno but is simpler in some ways: https://github.com/adrianbj/AdminRestrictBranch/blob/b5d27d1f118c34ba74d8548591a526513e68f48a/AdminRestrictBranch.module#L108 Hope I correctly understood what you wanted and that this helps.

Back again I have been playing around more with figuring out speed and as well as the panel generation time, it's also important to consider the size of the DOM for each panel (as I mentioned briefly in the last post). To that end, the Selector Panel now also shows the size of each panel in bytes/KB: I decided to remove the Page, Field, and Template objects from the PW Info panel which in my example has taken it from 500KB down to 70KB! I figure most of you don't need to see these often and you can easily output via fl(), d(), or bd() anyway when you do need them. As I mentioned, the Variables panel can also be very large in size (see mine above at 957KB) if you have many PW objects assigned to your own custom variables, so if this panel is large for you, I would recommend leaving it off by default. Anyway, hopefully the cleanup of the PW Info panel and the new panel size info will help you all to have much faster page loads when running Tracy.

Do you have the file compiler disabled on the production site?

For those of you experiencing slow page load times with Tracy enabled, I have some thoughts on this thanks to @Robin S setting up a demo site for me to play with. The two key panels that seem to slow things down are the Validator and Diagnostics panels. With all panels (except Diagnostics and Validator), load time are only about 1 second more than with Tracy completely disabled. If I enable those, then load times go up an extra 3 seconds (Validator is taking 2 seconds and Diagnostics 1 second). There is nothing I can do about speeding up the Validator because it requires a round trip to the validator website. Note that for me here in Canada, I find that Validator only takes 0.5 to 1 second, so I don't know how much it has to do with location. It will also be affected by how big the DOM is on the page being validated. So my recommendation is to leave that disabled by default and just turn it on in the Selector Panel when required. Same goes for the Diagnostics panel - I may be able to improve the speed of this one (in particular the reporting of file permissions takes a while), but for now I would recommend leaving it disabled by default. So I would love to hear from those having page load speed issues whether disabling Validator and Diagnostics makes a significant difference or not - it certainly does in my testing in certain situations. In case anyone is interested, this is my default panel selection and order: which results in this: and this load time: On the same page with Tracy disabled, this is the load time: I am certainly willing to sacrifice the extra half second or so. The other thing to notice about these are the MB/KB transferred numbers. The main panels in this regard is the PW Info panel - there are lots of PW objects sent to that. The other one that is potentially large is the Variables panel - if you set PW objects to your own variables, this can also become very large. Also, don't forget to check out the load times of the various panels in the Panel Selector to help you figure out your personal trade-off between load times and default functionality. And of course don't forget about the "Once" and "Sticky" options for enabling a panel just when you need it (like I have done here so you can see all my load times). Hope that helps, but also please let me know if you guys are having different experiences with certain panels being significantly slower than what you are seeing in my times.

Glad to hear it's working. As for that notice - you must have "Force Scream" mode checked in the config settings. It is expected behavior to see that notice because force scream disables PHP's silence/shutup operator: @ which is used on that line in Tracy to start the session. Personally I think they should check for the session first, rather than using @, but since the legacy version supports versions of PHP before session_status() was introduced, I guess maybe it's an acceptable alternative to the old if(session_id() == '') check. Either way, I would recommend turning off Force Stream unless you need it's functionality for a specific debug task. Otherwise you'll need to live with that notice. I could hack the core of the legacy version to remove it, but IIRC there are other uses of @ in the code so it won't be the only thing that needs fixing.

@Zeka and @Macrura - please try v2.4.0 - it should now work fine with the legacy version of the Tracy core selected. Of course I would still recommend switching to Master if you are running PHP >=5.4.4

Sorry @Zeka and @Macrura - I can confirm the issue when using the Legacy version of the Tracy core. I am not at my computer right now, but I'll take a look in the morning. If you are running PHP >=5.4.4 you should be running the Master version of the core, which I can confirm is working just fine. Sorry that I haven't been thoroughly testing the Legacy version with recent updates. PS What version of Tracy did you both upgrade from? I can't imagine it was from 2.3.8 - it would be great to know the last version you had that was working - thanks!

Very good point! However, the problem is that the tutorials page template uses the user that created the article as the listed author. I don't imagine Ryan would have a problem adding Francesco as a user with tutorial editing permissions, but I don't want to assume anything there, so the reviews page is the simplest place to list for the moment. Hopefully Ryan will be happy to change this at some point. PS - the reviews page is also something that is linked to in the SM article, so it may start getting more views even though it is a little hidden.

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.