adrian

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!

Yep - that's how it's working here for me. Are you trying to convert an existing Repeater field to a FieldsetPage field? I bet that is the problem. It looks like it is available an a type to change a repeater field to, but the settings might not actually be compatible - @ryan ?

Well I do agree with you on something at least - I also think that the PW logo should be to the admin home. I guess on smaller screens we need a hamburger icon for the that full menu sidebar. Back to my thought on accessing the tree - when you are editing a page, or on a subpage of Setup, Modules, etc you can click on the "Tree" icon and get the tree in that sidebar overlay - I think this is great, but you can't access it from these "parent" pages because there is not breadcrumbs on these pages. If the breadcrumbs were added to these pages, then you could access the tree sidebar panel from anywhere and I'd be happy As much as I want to embrace the iframe'd sidebar tree available in UiKit, it just doesn't quite feel right - partly it's the iframes, but mostly it's the width restriction that force the page list action buttons onto a second line. Being able to access the side panel overlay tree from everywhere would be a really nice compromise I think.

I completely agree. As much as I think whitespace/padding is important, I still prefer the default theme in this regard. I also think that the size of <h1> tags needs to be reduced significantly - it makes the title when editing a page huuuuuuge! Actually, can we go back to the default theme here also - no need for the title - just put it back in the breadcrumb and put the save/publish buttons on the same line as the breadcrumbs too. These are big showstoppers for me at the moment. The top of the Content / Children / Settings tabs is 215px down compared with 113px. That's 102px of wasted real estate at the top of the page! BTW - I really do like this new version of the UiKit theme - nice work Ryan Another idea I have - what about having the off-canvas menu (accessible from the PW icon) look like the sidebar menu on large screens. I don't think there is any functionality in duplicating the Setup, Modules, Access, User/Profile menus. I think the ability to bring up the page tree exactly the way it looks with the "Pagetree sidebar navigation" would be much more useful.

Hey @Robin S - I can't find it, but I am pretty sure I posted about this issue quite a while ago. I think this is critical and should be fixed in the core. I am sure there are more than a few modules that rely on a "repeater_{$field->name}" pattern for getting the template. They probably shouldn't, but it's also just one of those inconsistencies that shed a less than stellar light on PW (in my humble opinion). BTW, templates can use alternate fieldgroups - not sure how often this happens in practice, but that is the origin of that separation.

This actually doesn't seem to work for me and the prepend version of this <body pw-prepend='html-body' class='bgimage'></body> results in: <body id='html-body'><body class="bgimage">

Nice - I tried a couple of ideas with "prepend", but didn't see anything in the main blog post (http://processwire.com/blog/posts/processwire-3.0.62-and-more-on-markup-regions/) about using it like that. That does seem to work just fine - thanks!