adrian

Hi @Robin S - it's late here, so need to sleep, but quick questions - is this only a problem for custom "Site" actions? Is it fixed if you save the module config settings page? Let me know and I'll sort it out in the morning.

Small new feature that some of you may find useful. It is disabled by default so you will need to turn it on in the ProcessWire Info panel config settings section. Goto Page By ID which is available in the PW Info panel: It allows you to enter a page ID and click "View" or "Edit to be taken to the appropriate place. This was requested by a friend who is getting into PW development and I can see it being quite useful on sites where you reference key pages by ID in your template files and want quick access to view/edit them without browsing or typing a full URL, especially when you can't actually remember what pages they actually are

Of course, both new files and new folders should be set using the chmod values defined in the site/config.php file. wireMkDir() should take care of the folders, but file creation might have to be manually set?

Sorry - another request - what about the ability to create a new file in the current folder? Thanks for considering!

Nice catch - for some reason in PHP methods are not case sensitive - very weird IMO

That should work fine. I just tested via the Tracy console (injecting into ready.php). There is certainly no need to save the page because you are populating at render(). I don't think it should have anything to do with the name of your function being renderField, but you could try something that doesn't match a core public function. The other thing I would suggest (which I didn't do in the example below, but will work) is to use InputfieldInteger::render just to improve the efficiency a little. Also, try like I have in your ready.php file. The other problem might be that your module isn't installed or isn't being loaded - did you do a Modules > Refresh? Does it show up under the "Modules Loaded" section of the Debug Mode panel in Tracy?

Yeah, you have the page id correct. Did you try echoing: $settingsPage->id like I suggested? If that works, check other fields on that page and see if somehow it's just the store_hours field.

Actually, I do wonder about that - what version of PW is this? Maybe the behavior of get has changed since the early days, but I don't think so.

That won't matter because he is using $pages->get() rather than $pages->find() I think you do need to confirm 1006 and if that is correct, try $settingsPage->id to make sure that works - that way you can narrow down if it's a problem with the page or the store_hours field.

@matjazp - I am thinking about starting to use this, but was wondering your thoughts about maybe integrating https://github.com/spatie/image-optimizer instead or as well as https://github.com/psliwa/image-optimizer It uses a similar collection of tools for optimizing, but the main difference is that it also includes SVGO which of course adds support for "compressing" SVGs. I honestly haven't looked into the two libraries much more than that though, so there might be very valid reasons to stay with the one you have.

Thanks - I think that is much cleaner. The only thing I would suggest is adding a note to dotfiles checkbox to say that you can add htaccess and other extensions to the extensions filter to allow those.

Hi @Macrura - sorry for the confusion. I split the content of the PW Info panel into two panels - itself and the new Request Info panel. Discussion on this new panel starts here: https://processwire.com/talk/topic/12208-tracy-debugger/?do=findComment&comment=153033 You'll see that it has the page edit and template edit (if your code editor is configured for links) buttons at the bottom. The PW Info panel is now more about info and links for PW and the Request Info panel is about the current page/request. Be sure to check out the new options for both these panels in the module config settings as well - lots of great new tools. Let me know if you have any more questions about this.

Continuing on from yesterday's Console enhancements: 1) History stack now supports the state of text selection and the scroll position, so now much easier to run different versions without reselecting. 2) This selection and scroll position state is also recorded as you edit so it is also available if you reload your browser, etc so everything will be as you left it. 3) The editor window within the console should now always get focused when the panel itself is made visible (by hover or click). Previously this wasn't reliable. This makes running code much easier because the keyboard shortcuts for running will work without needing to click into the editor window to focus it. Unrelated to the Console panel - I have made the "Show debug bar in backend" checked by default on module install. Of course you can always uncheck this, but I find the debug bar just as useful in the backend, especially the Request Info panel when editing a page, template, field, or module settings. So consider this an attempt to enlighten new users to the benefits of it in the backend because I am sure many never bother to enable it. Please let me know if you find anything amiss with the new Console functionality.

I would go with the import option in BatchChildEditor (https://processwire.com/talk/topic/6102-batch-child-editor/) Batch Child Editor makes use of this library.

Really not sure either. It seems redundant to have to enter htaccess and then .htaccess in two different settings though. Maybe the Extensions filter should automatically allow files that are extension-only, like htaccess, gitignore, etc. Or maybe there is no need for the Dotfiles Whitelist and any extension that is listed in the Extensions filter should automatically be allowed? I think perhaps the latter makes most sense? Google seems a bit confused by that one

Thanks @matjazp - it works well! Just a few things: 1) You actually need to specify "htaccess" in the Extension filter setting as well as the dotfilesWhitelist. Not sure if this should be necessary or not? 2) Should the dotfilesWhitelist settings be labeled "Dotfiles Whitelist" ? 3) You have left in an unused "removeDotFiles()" method.

@Robin S - not sure what you think, but I actually don't think that "View site" really belongs under the user's name. Maybe it should be reserved for Profile and Logout and we should have a "Home" icon over on the left, just to the right of "Access"? Not sure what to do about the Debug option - I don't ever use it so maybe I am biased, but I think the link at the bottom right of the page is enough. I don't feel terribly strongly about this - just some quick late night thoughts , but I do think that some users may struggle to find the "View Site" link - I don't really think I would ever think to look under my username to find it.

What do you guys think about ignoring old backed up versions of modules? Currently the old versions of site modules that were created by Ryan's PW Upgrades module show up when browsing /site/modules. I am not sure there would ever be a reason to edit these via this module. It might clean things up a little to remove them. Same goes for .wire-x.x.x and .htaccess-x.x.x and .index-x.x.x PS I wouldn't want to remove all .* files though in case someone does want to use this to edit the active .htaccess file.

Great idea - I forgot about the blog component to that profile.

That profile is pretty old now. Why not try this instead: http://modules.processwire.com/modules/process-blog/

Sorry for the quick follow up. The latest version now supports non-contiguous and partial line selections, so now you can do this: Note the partial line selections in this example:

This is a minor change, but I am actually really excited by it The Console panel now supports running just the selected code. I often find myself using the Console panel to test variations of code to see which is faster / more efficient. The time and memory usage is displayed after each request, but it's often a bit of a pain to keep commenting out some of the code, testing it, and then uncommenting that and commenting out the other, etc. Now you can have multiple functional bits of code and just run one at a time. You can see in these examples that I am selecting different chunks of code to be run and I can clearly see which one uses more time and memory.

Page Protector doesn't require access to the admin to work. It's easy to create your own logout link (https://processwire.com/talk/topic/684-client-logout-page/). Page Protector lets you style the login page however you want

Of course: $page->of(false); $page->phone->country = '1'; $page->phone->area_code = '123'; $page->phone->number = '4567890'; $page->phone->extension = '987'; $page->save('phone');

Hi everyone, Relatively major new version just released: 1) New run on init, ready, finished option in Console panel I am not sure how popular this will be, but it lets you inject code from the Console panel into the PW process at init, ready, or finished. This lets you test hooks and other code that you would normally add to the init.php, ready.php, or finished.php files without having to edit files, and also without affecting anyone else viewing or working on the site. This screenshot should give you the idea: As you can see, I have added a hook to change the page title on saveReady. The way it currently works is that you: enter your code click Run to "register" the code for the next page request select "init", "ready", or "finished" as the place to have it injected In this example, you would then save the current page and the hook would be injected into init() and the page title will change If you don't switch back to "off" when you are done testing, it will expire in 5 minutes. The Console panel icon will also change to a red color to provide a visual indicator that you have an injection running on each page request. Please give me feedback on this feature - if you guys are annoyed by having those options visible and you never plan on using this, I'll make it an option that can be turned off completely. 2) Make User Switcher available without setting to "DEVELOPMENT" mode When I initially built the User Switcher I was a little paranoid about the possible security implications so went a little overboard by making it only available when hardcoded to DEVELOPMENT mode. But in reality this didn't make any difference and just made it more difficult to use, so now you'll find it easier to use - it's such a great feature! If you haven't used it, give it a go! 3) Options to hide debug bar from Form Builder iframe Having the debug bar in a Form Builder iframe can be useful, but also a visual annoyance so now you can disable if you want. 4) Hide User Bar from Form Builder iframe This is automatic as there is no reason for the User Bar to appear in a Form Builder iframe and it is confusing for users and ugly. 5) Restricted panels now works with "tracy-restricted-panels" role as well as permission (needed due to recent PW core change) Due to a recent change in the PW core, it is no longer possible to edit the permissions for the superuser role, so I have now added support for assigning a "tracy-restricted-panels" role to a user. The "Restricted Panels" defined will then be applied to users with this role. The permission option will continue to work for other non-superusers. 6) ACE editor update 7) Other bug fixes / tweaks