adrian

Hi @Mike Rockett - absolutely happy to style these differently. @tpr already did a great job of improving the look of the panels - any chance you feel like having a go at improving the bluescreen (that's what the Tracy devs call it) error page? It would be nice to match the look of the panels for the various tables (Callstack, Variables, etc) on the bluescreen as well. If you don't have time, I can have a go, but just thought I'd ask

Or perhaps a new panel in Tracy - a dedicated snippet runner (with no editing interface) that pulls & runs snippets from a defined folder? This could be pretty handy - what do you think? Or again, maybe actions for AdminActions. Remember that actions don't need options page - they can be as simple as: class UnpublishAboutPage extends ProcessAdminActions { protected function executeAction() { $p = $this->pages->get('/about/'); $p->addStatus(Page::statusUnpublished); $p->save(); return true; } }

Hi @Robin S - thanks for your thoughts on this - I am certainly willing to think about file based storage of snippets, but a few thoughts/clarifications.... The console panel is actually locked to superusers only - I don't think it should be available to any other Tracy authorized users - it's just potentially too destructive. I think my AdminActions module is a much better tool for making snippets available to non-superusers - you can control who has access to what and you can provide actions where the snippets aren't editable. I can see why this is partly an advantage, but I actually really like the console panel - it has PHP code highlighting, completion and syntax checking. Admittedly it doesn't have PW code completion, but we could actually add that. The main reason I like it is that I type and then OPT + Enter and the code executes, which to me is much quicker than using my code editor, hitting save, reloading the site in my browser and then running the snippet from the console panel. I also worry about getting snippets out of sync - if you make changes in the Console panel and save your code editor should instantly reflect those changes to the file on disk (at least SublimeText does), but what about saving changes in your code editor - how does the Console panel get updated? What if you then save again in the Console panel - you'll overwrite the changes to the file that you made in your code editor. It looks like PHP's iNotify or FAM might work for updating the console panel, but they are not standard and sound resource intensive to me. Maybe I am overthinking this - what do you think about the issues I have raised? Definitely a nice possibility - I think we'd be storing snippet files in site/assets/cache/TracyDebugger, so as long as this directory is included in your versioning then I guess it would be ok. Agreed that isn't super easy at the moment. I use my ModuleSettingsImportExport module to copy my Tracy settings (and therefor all my snippets) to new site installs. Obviously file-based snippets would be easier though. I actually think in this case we'd want a separate file for each snippet, rather than having "some scheme for labelling and delimiting the snippets within the file", as you noted at the end of your post. Definitely a good point, although I haven't come across that set - I think most snippets tend to be pretty short, but definitely a possibility that would be nice to avoid. Looking forward to hearing your (and others) thoughts on this.

Take a look at: http://modules.processwire.com/modules/lazy-cron/ You can set that up to check at whatever time interval to make an API call to remove unverified accounts.

You can also store it as a snippet in Tracy's Console panel - note the snippet name in the right sidebar. That way it will always be available and you won't have to remember it.

If you outline exactly what you need maybe we can modify the Page Manipulator action, or create a new action designed specifically for deleting large numbers of users - I think this might be the best option. I am happy to build this if you mockup the interface.

Or check out the "Field List & Values" section of the PW Info panel in Tracy, which takes things a step further and explodes values which returns arrays (like images) and provides other details about the fields:

Nice one @abdus ! Just a quick tip for others. You can also test building hooks directly in the Console panel.

Thanks for tracking that down. Would you mind posting a new message on the Pro Drafts module board please ?

The other useful tool here is the Module Disabler panel in Tracy: https://processwire.com/blog/posts/introducing-tracy-debugger/#module-disabler-panel Alternatively if you decide to uninstall modules, make sure you have ModuleSettingsImportExport installed so that it takes care of backing up module settings so you can restore when you reinstall a module. Sorry, lots of self-promotion there

For me it's been on one server in particular, but in general live servers are much worse than local dev, although I have seen it slow on a friend's local dev as well and I do remember others (eg @kongondo) reporting slow loading of the bar on local dev. But yes, hopefully much better now!

Major speed improvement ! I have been in dialog with the Tracy core dev (David Grudl) for the last few hours and he has come up with a way to have all the advantages of the current version ("Master") of the Tracy core (including the AJAX bar), without the potentially huge speed penalty - the old ("Legacy") version was always much faster. On some servers, the new version was painfully slow at times. For those interested, the slowdown was due to the use of $_SESSION to store the content of the debug bar. This was sometimes huge (especially will all the custom panels this PW implementation has). This new version doesn't use sessions for the main bar and because the AJAX bar doesn't show the custom panels, the size of the session is kept MUCH smaller. This is brand new, but so far I don't see any side-effects, but please start using it and let me know if you come across any problems, or just feel free to comment on how much better it is! Maybe even drop David a thank you if you feel inclined.

Mine are sorted alphabetically. I would like to know why your's aren't!

This fork of AdminBar (https://github.com/teppokoivula/AdminBar) can be very useful in this situation. Style it to match your site and it's a very quick way to give logged in users the ability to edit and add new child pages. It won't ever be as flexible as building your own frontend form and processing using the PW API, but it's very easy when you have complex forms to reproduce, especially if there is image upload and ASM type select fields to reproduce. This screenshot shows that you can add a "New +" child page when viewing the main portal parent. This screeencast shows editing an existing entry:

This is the entry I'd be looking at (screenshot below). Make sure you have debug mode on, and having Tracy installed may also help because it should report on errors in AJAX requests, although it may not be a PHP error, but rather an ill-formed JSON response, which is why you should also check out the response tab of that file in the screenshot.

I would start looking for JS errors in the console and in particular for the ajax called image upload file on the Network tab. Make sure you disable cache on the console in Chrome.

Lots more updates today. 1) I have changed the default zIndex of the debug bar panels. In the Tracy core they are set at "20000" and go up from there as new panels are displayed, but these were always above the PW dropdown menus which meant you always had to close a panel to access menu items - very annoying. I have set them to "100" as a default, but this is also now configurable in the module settings so if you find you are having problems (especially on the frontend of your sites), you can adjust as needed. Please let me know though if you think there is a better default than 100. 2) Now if you are editing a field, template, or module in the admin, the Console panel will have access to: $field, $template, or $module, respectively which will be the object for the currently edited one. So if you are editing the "body" field, instead of doing something like: d($fields->get("body")); you can just do: d($field); 3) Again, when editing a field, template, or module, the ProcessWire Info panel now contains a new section at the top with details for the edited object. This is an example of the "body" field being edited. 4) The ProcessWire Info panel now uses the exact name of the PW property, rather than the old capitalized and spaced label. This means you can see what you will need to use in your templates to get a certain property. Cheers!

Hi @Jota, Just wondering if you'd be willing to pay for a little extra time to upgrade the site to PW 3. Depending on the complexity of the site, it could just require a little testing, or there could be a few hours of tweaking things, but I would expect the former. PW 2.3 is so old now that it would be great for you (or your clients) to experience what it is like these days.

It's not an extra ">" tag - it's a string and makes the link look like a breadcrumb, eg. Furniture > Chairs As for the other domain issue you are having - sorry I haven't ever used the multisite module, so not the best person to help on that side of things.

What it returns is what your search.php template file returns - if you tweak that to return ->httpUrl you will get what you're looking for. In mine for example: foreach($viewableMatches as $m) { $content .= '<p><a href="'.$m->httpUrl.'">' . $m->parent->title . ' > ' . $m->title . '</a></p>'; }

This module will take care of this for you: http://modules.processwire.com/modules/process404-search/ It still returns a proper 404 header, although I am no longer convinced this module/technique is a good idea: https://processwire.com/blog/posts/optimizing-404s-in-processwire/

Just added support for $options when using the dump() / d() method. It lets you specify the maxLength, maxDepth etc parameters the same way you can with bd() calls. I couldn't manage to get an equivalent to barDumpLive() / bdl() working at the moment, but making the $options available should still be very helpful in the Console panel when inspecting large objects. Also if you have the "Reference page being edited" option checked, this now also applies to edited Users, Roles, and Permissions which means that the ProcessWire Info panel will display details of these, rather than the parent process and in the console panel, $page will reference the edited user/role/permission, which should be a helpful addition. One last thing (which took most of my day) - the recent SessionHandlerDB fix for showing the "redirect" debug bar was resulting in various PW notices being lost and not displayed. I think this should now be fixed, but please let me know if you find any other side-effects of that original fix.

I would argue that as @louisstephens pointed out, much of the php you need is simple echo'ing and foreach'ing and a willingness to learn. As for the problem with the blog, perhaps we should get the blog module author @kongondo in on the discussion to see if he can get you up and running.

Ok, It now supports a comma-separated list of email addresses and it has been rebranded as "Notify Other Users" and it now uses "To" for sending to these addresses as well. Please let me know if you see any problems.

Yeah, it seems like an omission in randomPass() to not be able to generate a password that matches the settings for the system "pass" field. Your discussion here made me take another look at the generate password settings in my EmailNewUser module. I was about to remove those options and make the generate password method use randPass() with the appropriate options as they are stored in the "pass" field settings, but the problem is that randPass() doesn't support the "Complexify Factor" setting and it also uses minLenth settings for each character type, rather than an overall min password length (which is what the password field settings need. It also doesn't support the "Word Ban" mode option. Seems like a feature request for the core?