adrian

Wow - I totally agree - they are beautiful. Lots of the FA ones really are pretty poor.

Maybe it would help to know a little more about your scenario. Perhaps you could try Page::viewable - it checks to see if a template file exists?

You can hook: ProcessPageView::pageNotFound

Agreed! While I love the idea of this module and especially the easy setup of option type fields (checkbox, ASM, etc) without needing to point to somewhere for the source of the options, I would like to be able to define the options via PHP when I want. Maybe the approach I have taken in AdminActions might work ok here as well, eg: $fieldOptions = array(); foreach($this->wire('fields') as $field) { if ($field->flags & Field::flagSystem || $field->flags & Field::flagPermanent) continue; if(count($field->getFieldgroups()) === 0) $fieldOptions[$field->id] = $field->label ? $field->label . ' (' . $field->name . ')' : $field->name; } return array( array( 'name' => 'fields', 'label' => 'Fields', 'description' => 'Select the fields you want to delete', 'notes' => 'Note that all fields listed are not used by any templates and should therefore be safe to delete', 'type' => 'checkboxes', 'options' => $fieldOptions, 'required' => true ) );

Tracy will report all those errors even with debug mode off - just use the "Force superuser into development mode" option so that it shows on a live production site when you are logged in.

Hi @Robin S - thanks for those reports/ideas. I have added a new $title variable to actions. This is optional, but recommended. I have fixed the annoying "Actions" title on hover. But, regarding having new actions automatically enabled for superusers, I am not so sure. I purposely don't enable any actions for anyone by default. There are a lot there and there will potentially be many more in the future. My thought is that the list could become overwhelming and many/most devs might actually prefer to just enable those that they will use on a semi-regular basis. That said, I am willing to hear more arguments from others in support of this Cheers!

Nice. How about some radios for more focused searches? API reference - site:processwire.com/api/ Forums - site:processwire.com/talk/ Blog - site:processwire.com/blog/ Yeah, I was thinking about doing that - just implemented:

A couple more options for searching the PW website more easily: 1) New search feature in the ProcessWire Info panel in TracyDebugger https://processwire.com/talk/topic/12208-tracy-debugger/?do=findComment&comment=153342 2) Custom search for Alfred (customizable Spotlight type app for Mac) Simply type "pw" and then your search term: These are the settings to configure Alfred to do this search: https://www.google.com/search?q=site%3Aprocesswire.com%2F {query} You might also want to consider adding the following: pwapi : https://www.google.com/search?q=site%3Aprocesswire.com%2Fapi%2Fref%2F {query} pwblog : https://www.google.com/search?q=site%3Aprocesswire.com%2Fblog%2F {query} pwtalk : https://www.google.com/search?q=site%3Aprocesswire.com%2Ftalk%2F {query}

New Search ProcessWire website feature in the ProcessWire Info Panel. For updates to old Tracy installs, you will need to manually enable this feature in the module settings. It is on by default in new installs. Any term you type in the box will take you to a Google site search for the PW website, eg a search for Tracy will take you to the results for a site:processwire.com/ tracy Hopefully you guys find this useful!

What about this in your ready.php file: $this->addHookBefore("InputfieldCheckboxes::render", function($event) { if($event->object->id != 'Inputfield_roles') return; $optionsWithTitles = array(); foreach($event->object->options as $id => $name) { $roleTitle = $this->wire('roles')->get($id)->title; $optionsWithTitles[$id] = $roleTitle != '' ? $roleTitle . ' ('.$name.')' : $name; } $event->object->options = $optionsWithTitles; }); In this screenshot I have only added a title to the "Editor" role:

Hi @mel47 - yeah, that's confusing to me too. I know what's stopping them from being displayed, but still not sure exactly why - I am thinking it might be a Windows path issue at this stage. Can you please post a screenshot of the Server Request section expanded. If it's easier, just the bottom half of it will be fine, from SERVER_NAME onwards. I am sure it will be a simple fix, but I need to know what some of those values are returning for you. Thanks!

Thanks for noticing that - it should be fixed in the latest version. Because there are settings for this module on every page (Settings tab), saving the page was saving the settings. Now I check to see if there are any changes before saving. Please let me know if it works as expected for you.

This is very strange and timely @Guy Verville - I just upgraded to High Sierra and my homebrew AMP stack broke. After getting everything working again, I was also getting a 404 for the admin page. Turns out I didn't have the mod_rewrite apache module loaded. Not sure if that's what is going on for you, but definitely something to check.

Sorry for the trouble you had with the Batch Child Editor module. I believe that was fixed a LONG time ago. The module is now up to version 1.6.13 Please consider installing the ProcessWire Upgrades module so you will be notified when there are updates to installed modules.

Best of luck with the project Margie! If you happen to need any help from a marine scientist come web developer who speaks Strayan, just let me know ?

Hey @kongondo - I am actually just playing around with VSCode right now and autocompletion for PW seems weird. Some of the wire functions outside of class scope show up, eg: but that's not all of them, and nothing in any of the PW classes shows up at all. VSCode seemed to index my entire project folder, so I think it should have everything. Any tips you have discovered for this? PS @abdus - I took a quick looks at PHPStorm, but it seemed really sluggish (even after indexing had finished) - did you do any tweaks to get it snappy enough to work with?

Just an FYI - in the Console panel you can now do mixed HTML/PHP without needing to add a php closing tag first. <p>Welcome to the <?=$page->name?> page!</p> File-based snippets (Snippet Runner) can be plain html, plain php, or mixed html/php, but they must have an opening php tag as per normal PHP requirements. The Console panel does not require an opening PHP tag (although having one will still work). You can use mixed html/php as per the example above, but for a pure HTML file you will need an initial ?> before the HTML to make it work, eg: ?> <p>Welcome to this page</p> Plain html in the Console seems like a pretty uncommon use case, so hopefully this gives us the most flexibility without too much weirdness.

Sorry about that - I am not seeing that, but I see where it's coming from. Please try 4.6.5 and let me know. PS Don't forget to enable the new Request Info panel which now contains most of the info from the old version of the PW Info panel

I've just made a few more tweaks so that now you can have mixed html and php in your snippet file. For example this: <p>Welcome to the <?=$page->name?> page!</p> will return: This might come in handy for testing snippets of template code if you use a direct output approach, or markup regions, or anything else where you are embedding php into HTML tags. The only downside is that now pure PHP snippet files must start with a php open tag. I think this is a quite acceptable compromise as I couldn't imagine writing code in my editor without it. You can also do this with the Console Panel, but you have to start the snippet with ?> to close the automatically added PHP tag, eg: ?> <p>Welcome to the <?=$page->name?> page!</p> This is because the Console Panel always adds an opening PHP tag if it doesn't find one - I think this is best here because it's nice to not have to manually add when doing a quick code test. Anyone have any thoughts on these new abilities - does anything seem illogical?

@Robin S - please try the latest version which supports declared namespaces in both Snippet Runner and Console panels.

Yeah, it is certainly up there Glad it's working well for you. The focusing of the Run button was initially to help with helping target the eventListener for the keyboard shortcut, but I found what I think it a better way without having conflicts if both the Console and Snippet Runner panels are open at once. Even after figuring this out, I decided to keep the focus of the Run button as a visual reminder that loading != running. Let me look into this - should be a pretty simple fix.

Ok, they are now a list of icons with labels by default with an option to turn off the labels in the module settings. Hope that helps! Of course if you are upgrading you will need to check the option.

Hi @Robin S - I have fixed both those bugs you reported - thanks for that. As far as using a File field - actions can use any PW code, so this is certainly possible. You could make use of a FieldtypeFile field using the same approach that Ryan uses in his ImportPagesCSV module, or you could use a Markup field and add a "manual" <input type="file" /> field - whatever you prefer really. I don't think the main code in AdminActions needs any adjustments to support these, but let me know if there is anything I can do.

Major new version just released. There are quite a lot of changes and it fact it jumped two major point versions because I added two new panels. Here are the highlights! 1) New Snippets Runner panel - as discussed in the last few posts, this is similar to the Console panel, but all snippets are stored in the filesystem. By default they are stored in /site/templates/TracyDebugger/snippets/, but you can change that to /site/asets/TracyDebugger/snippets/ if you prefer. Running a loaded snippet grabs the latest version each time, so simply save in your code editor, switch to your browser and trigger Run. It has access to all PW variables and can reference the currently edited page etc, just like the Console panel. 2) New Request Info panel - this panel contains most of the info from the ProcessWire Info panel, but also adds the following: Server request (this is a dump of all items from $_SERVER Input GET, POST, & Cookies (these used to be in the Debug Mode panel, but I think this panel is more appropriate for them) PLEASE NOTE: This panel is set to be loaded by default when Tracy is installed, but if you are upgrading an existing Tracy install, you will need to manually add this to be loaded in the config settings. 3) Revised ProcessWire Info panel - this is now much simpler and now contains: API variables (with links to PW docs for each) Core classes (with links to PW docs for each) Config data (dump of $config var) Versions List (an easily copyable list of server and PW core and module versions) Admin Links (including Login, Logout, and Documentation Links 4) Revised Debug Mode panel - several elements moved to Request Info and ProcessWire Info panels. Most of these sections could justifiably belong on the Request Info panel, but I think you are less likely to use most of these on a regular basis - they are more technical than the sections in the Request Info panel. 5) Request Info and Debug Mode panels now load in Redirect and AJAX bars I limit the panels that show up on the Redirect and AJAX bars to ones that will have different content. For example, there is no point loading PHP Info, Captain Hook, etc for these additional bars. Part of my reason for splitting up the ProcessWire Info panel into the new Request Info panel is because there is no point having admin links etc being populated to the additional bars. So you'll see that the ProcessWire Info panel is not loaded for the additional bars, but the Request Info and Debug Mode panels are. Now you can see the details of each page request (whether it's a redirect or AJAX, or ordinary). The panel on the left is after a POST form submission on a regular PW page and the one on the right is an AJAX call to a non-PW PHP script which is why there is no "Page Info" section. In this case, you can see the details of the request via the "Server Request" section which shows: It also shows the GET and POST data for the request, and the edit link will open that /data/testajax.php file in your code editor. 6) Lots of other tweaks There are lots of other tweaks, but the one that might cause a few weird issues is the way the debug bar and panel styles are loaded. The Tracy core now makes this easier, but I have noticed some instances where the styles are not being applied. I think it always comes down to browser caching, but if you find that a hard reload doesn't fix things, please let me know and I'll investigate further. Feedback There are lots of changes in this version, so please let me know if you have any suggestions - did I mess with something that you loved, but now hate, or do you just have ideas for how something could be done better? Please let me know!

Why not use a variable defined in the module class, eg: protected $clearPassword and populated via: $this->clearPassword in the hook's function. This will be available throughout the module's functions. This is what I did in my EmailNewUser that I linked to above.