adrian

Have you tried? I honestly haven't played with images and the Markup module, but it would be worth seeing if you can, even if you need to parse it out from the enclosure yourself. I know it's old (and there are likely more modern solutions), but magpierss works with images.

Not sure - I haven't looked into it, but I based on this question, are you just generating the RSS feed so you can load it back into another site? If this is the case, maybe you should consider another strategy like making a simple REST service?

Try this version:

@Surikat - perhaps you are just trying to enlighten us all about RedCat and we appreciate that, but it does smell a little like advertising. You should know that ProcessWire is actually a framework first and the optional CMS component is actually built on top of this framework. I know this is not obvious from reading some of the blurbs on the website, but this is one of the main reasons why ProcessWire is so great because you have all the tools from the framework available for your use on the frontend, or to build your own CMS on top of it if you wish.

Can't you add it to the Character Replacements list in the Page Name config settings: /module/edit?name=InputfieldPageName

Just added color significance to PW and Tracy Log panel icons. Red for errors, exception, critical Orange for everything else, including warnings, info, debug, and any custom names PW logs Green for none All colors are based on log entries from the last 5 seconds which should cover everything loaded/redirected etc during the last page load. The idea being that you don't want the red or orange colors to be triggered from an error that was recorded days ago, even if it's the most recent entry. Hopefully this logic makes sense and it provides a useful visual cue to let you know that something was just logged. PS - as part of this I needed a different icon for the Tracy log panel - you'll see it's now burning campfire logs - it's actually hard to find a nice small icon for logs

Thanks again for all that. The one that stands out is the ToDo panel - I honestly haven't tested that on a large site with many template php/css/js files, so perhaps that is expected. Maybe I need to implement some caching so that it only scans files if they have been changed since the last scan. That should help with that significantly. Actually, you should take a look at the ToDo panel config settings and exclude any js/css from external libraries - I bet that is what is slowing that down. My ToDo panel renders in 0.03s compared to your 1.27s! I was actually thinking about adding caching to the Validator panel as well although that one will be a little more complex as it will require storing the rendered HTML so it can be compared. Regarding the generally slow nature of your local dev setup - have you read this thread: I feel like it might be the reason Tracy is running so slow - would be worth a look regardless as it seems like you are experiencing slow page loads even without Tracy, although of course I don't know what resources your page is loading.

You currently have this: Note that there is no "/" before "site", which means it will try to load: http://diofralealtrecoseparla.newageofcattolicesimo.it/site/templates/js/site/templates/css/style-wide.css instead of: http://diofralealtrecoseparla.newageofcattolicesimo.it/site/templates/css/style-wide.css PS Have a read here about urls: http://ifyoucodeittheywill.com/2009/03/absolute-relative-and-root-relative-urls/

Sorry, I read this: and assumed that even though the page load is faster, Tracy is still making the page load around 6 seconds. So am I right in assuming that on the live server you can actually leave Tracy turned on? So a quick question for you - on your local dev setup, what are the page load times for the same page: with Tracy completely uninstalled Tracy installed, but with the "enabled" checkbox unchecked Tracy installed and enabled, but with no additional panels enabled Installed, enabled and with the default set of panels Installed, enabled and with all panels enabled Can you also post a screenshot of the Panel Selector when all panels are enabled so I can see those s/kb values? Thanks again!

@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/