adrian

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?

Hi @Macrura - do you have any thoughts on how this would actually look? I can envision the clear/delete options, but you mention "look at". Do you want to be able to actually preview the contents of wireCache items? Currently I use the Console panel for this: d($cache->get("hello-world")); but I can see the advantage of being able to peruse them all. I just worry that some might be quite large. Any thoughts on what you'd like for this feature?

Remember that ModuleToolkit can batch install modules with a list of module class names.

Hi @Robin S - glad you like it Yes, if the API Explorer is installed it will link to those and if not, it will link to the API docs on the PW website. On a related note, the links from the API Variables and Core Classes sections on the Debug Mode panel behave the same way. As for opening in new tab - I am honestly not sure about this. I struggle with this a lot - I used to be all about new tab for external links and same tab for local links (so long as it wouldn't result in a broken form submission / loss of user input). However these days I mostly don't go with new tab for external links at all - I think the user should have the choice. Also, in this case the user of Tracy is going to be a developer and they know about middle-click, three-finger-click, or right-click new tab, so I am tempted to leave it up to them. I would like input from other Tracy users on this though, because it is a grey area and it could result in a loss of form data. Keep in mind that all links from Tracy (especially the PW Info panel) are same tab, so I think I have been consistent here. Any strong thoughts from any of you out there?

Hi @d'Hinnisdaël - thanks for noticing this issue and putting together a fix. I am actually wondering if there is actually any point in using the bcc option even when it's available. Maybe I should just relabel it as "Notify other admin users" and make use of additional "To" email addresses. Maybe it should even support a comma-seperated list in case you want to notify more than one user. Any thoughts on this before I implement?

Thank you - awesome to have! The main thing I am missing at the moment is the full row hover And the position of the "Disable AdminOnSteroids" link is driving me a little crazy A couple of other things I have noticed: There is no support for the stick header/nav when using the traditional layout option. In sidebar mode it is built into the theme, but I don't like the iframe implementation. There is a weird layout issue with AOS on - note the doubled and missing borders on these elements Thanks for all your work on this!

Hey @tpr - any chance you could add the "Show pagelist actions on full row hover" tweak to the sidepanel tree - the one that shows when you click this icon in the breadcrumbs. I am starting to get into the habit of using that panel as a way to access the tree and I am really missing the full row hover. On another note - what are your thoughts on supporting the new UiKit theme now? It is starting to look more usable (although I must admit I still don't see any real advantages over an AOS tweaked default theme), but it would be a nice option to have going forward. No pressure by the way - I know it's going to become painful keeping up with three different themes. It will be interesting to see what happens - will UiKit takeover as default - will the others stop getting core upgrades? Comes back to my desire for one theme which is easily skinnable, rather than different structures!