adrian

Thanks - I wasn't sure what was used (I should have looked at your previous post) - I always use gtmetrix so just went with that.

https://gtmetrix.com/reports/cmscritic.com/IHjrEiKy The page load is substantially quicker (3.2s) and there are a lot less requests (61), but the score is still a D due to a few things which should be easy fixes, and are not PW related. The page is still 2.5MB, but again, not a PW issue.

But what if it's not installed? I am guessing you will revert to a popup? I am sure you won't, but please don't automatically install it

I have updated the screenshot and added in Jonathan's details - I have kept Ryan in there as well because he did the initial coding which I think formed the basis for what Jonathan worked from. Hopefully that's all ok.

Just wanted to let everyone here know that the Console panel just received a fix regarding UTF8 encoding: The first time you load the console after the update you'll see your code as base64 encoded, but once you enter something new it will work fine after that. Please let me know if you notice any other problems.

Hi again, Ok, the console panel in the latest version of Tracy now works fine. When I initially coded it I was using GET not POST (I don't even remember why, but obviously a bad idea), but it meant I needed to base64 encode everything which was breaking the UTF8 of your content. Even though I switched to POST even before I released it, I never removed the base64. I could have recoded it as utf8 which actually does work, but I think the right thing to do is simply remove the base64 encoding, which has also made the console much snappier. Anyway, you will notice that the first time you open the console (after upgrading to the latest version) that the contents will be base64. After that you should be fine. Please let me know if there are any other issues along these lines or any other situations where you feel you can't trust the console panel. PS Sorry for the time everyone spent on this!

I can confirm that it works fine here from a template file, but as @LostKobrakai there is something in the Tracy console AJAX request that is breaking the encoding. I'll try to look into it sometime today and provide a fix if I can.

The code I gave you does pretty much that assuming you have a separate field for the teaser (I called it summary). If you want an automatic teaser than you need to truncate the body field (or whatever you might have called it). Instead of $article->summary, you can try something like: substr($article->body, 0, 300) Of course you can get much fancier with automatic teasers, but that is a PHP question and there are lots of answers on the web about that. Also, if you want the code I had to work from the homepage while the articles are perhaps under an Articles child of home, then try this: foreach($pages->get("/articles/")->children("limit=10, sort=-published_date") as $article) { echo "<a href='$article->url'>$article->title<\a>".substr($article->body, 0, 300); }

I also just removed the horst-n author name from the dropdown list of authors.

My guess is that you mean a list of articles with perhaps a summary and then each one links to the full article. You would construct your site to have a child page for each article. Then you can do foreach($page->children("limit=10, sort=-published_date") as $article) { echo "<a href='$article->url'>$article->title<\a>$article->summary"; } That will display titles and summaries of the last 10 articles with direct links to the page where the full article lives. Apologies for the brevity and code formatting - not a good idea to try this on a phone while your laptop is running updates

I have just added a new config option for hiding the debug bar in modals. @tpr and I discussed this above and we decided to show in regular modals, but hide in inline ones, but the tripling up of the bar when editing a page in a modal and then editing an image from that page was driving me nuts, so now the default is to have it disabled in both modal types, but you can uncheck these if you want.

Here's another one: Seems to happen after a field has been collapsed.

Great to hear. I have restored your listing on the sites page: http://processwire.com/about/sites/list/cms-critic/ @Jonathan Lahijani - if you want to send me the details you want entered in the Made By section, I'll update that too!

Glad it's working. Just a couple of FYIs for using Tracy with modules in case you missed them from above. If it's an autoload module, then sometimes Tracy isn't loaded before the module (nothing I can do about this until Ryan gets back to me). The other thing is that sometimes it pays to use the Dumps Recorder panel with "Preserve Dumps" checked as sometimes things can get lost during redirects within modules. This way, a simple reload will refresh the content of that panel and you'll have your dump.

bd() and all the other shortcuts are available in the global namespace so you shouldn't need to do anything special. Is that not working for you? Does it then actually work with use\Debugger" & "Debugger::barDump(...) ? If so, could you perhaps give me more info about where in the module you are trying to make the call?

What version of PW? You need 3.0.5+ for nested repeaters to work properly. https://processwire.com/blog/posts/more-repeaters-repeater-matrix-and-new-field-rendering/ (read the "New support for nested repeaters" section). You might also want to consider the repeater matrix option which is only mentioned in that post.

The FileCompiler only compiles files if there has been a change to a file since it's last compilation. So once you deploy, if you don't change any template files. or update any modules, the file compiler doesn't do anything. If you then make a change, it will compile the one time (likely when you view your changes) and that is it, so the users will probably never have to wait for it to compile. That said, the only time I ever notice the file compiler is during an upgrade of a site from 2.x to 3.x when it has to compile all template and module files at once. I have never noticed the time for compiling one file. If you are seeing peaks from the file compiler on every page load, maybe there is something amiss?

Just posting a teaser at the moment because I am not yet sure if this should be a standalone module, or part of the still unreleased Module Toolkit (https://processwire.com/talk/topic/8410-module-toolkit/). Now available here: https://processwire.com/talk/topic/15702-module-settings-import-export/ It is quite simple in its execution - it adds a Settings Import / Export collapsed fieldset to the top of the module settings page of all modules. You can copy settings from one install and paste into another and click "Import Settings". It works quite like PW's core template and field import/export functionality. Simple as that PM me if anyone is keen to try it before I decide where and how it should be released. Settings are automatically saved when you uninstall a module, so you have an easy way to restore them when you uninstall. Anyone have any thoughts on any of this?

Definitely 3! Here is a slightly outdated review of changes between 2 and 3: https://processwire.com/blog/posts/review-of-processwire-3.x-so-far/#whats-changed-between-2.x-and-3.x

boo! hiss! Just kidding I actually don't mind it at all now that the crop again option is a button rather than a text link.

It looks to me like they should both work just fine. Just one thing to mention though. You could simplify the whole thing to: if($wire->users->count("email=$em") === 0) { $validMail = 1; } else { $validMail = 0; } or in my mind, even better: $validEmail = $wire->users->count("email=$em") === 0 ? true : false; Of course you could do the 1 : 0, but I think true : false is more appropriate because then later on you can do: if($validEmail) { Note in both cases I am also using 'users' instead of 'pages' which is more descriptive in this case. Also, using the PW count() method is much more efficient as it doesn't actually grab all the data, it just counts matches. You can even take it one step further if you only need to check if it's a valid email just one time: if($wire->users->count("email=$em") === 0) { //email is valid so do whatever here - maybe this is where you add them like: $u = new User() // etc etc }

Maybe at job for @tpr and AdminOnSteroids?

Here are a couple of example modules that do this already: http://modules.processwire.com/modules/process-email-to-page/ http://modules.processwire.com/modules/process-custom-upload-names/ The approach is the same in both, although I don't honestly think you should steal code directly as it's not particularly pretty (a big understatement) - I'd like to redo the approach for both at some point), but it will hopefully give you a starting point.

yeoman generator for processwire env: https://www.npmjs.com/package/generator-processwire

Just wanted to say a special thanks for this comment - I am very glad to hear it's been so useful to you - several of you have also been instrumental in making Tracy as useful as it is, so thanks to you all as well!