adrian

Thanks for testing @bernhard - I'll see if I can duplicate the issues you are seeing with layout - it seems fine here, but I'll test some more and see if I can try on a Windows machine. I agree that I would mostly choose a real terminal over this, but if I don't know the credentials for the server (or I am away from my computer), this is a pretty good backup, which is the way I view this feature. Regarding security - I thought through this already and here's my reasons why it's not an issue: 1) The file is not available outside the process module - PW's htaccess restrictions ensure that. 2) The process module requires superuser permission. 3) It's no more dangerous than the Console panel or Hanna code - both let you run shell_exec commands on the server anyway. This just provides a nicer interface and returns the output for you. That said, if anyone can think of a security concern that I have overlooked, please let me know.

I had @tpr take a quick look and it sounded like it worked, but I don't think he tested thoroughly. Maybe @bernhard would be willing to have a look as well. I know it works well on Mac and Linux.

Hi everyone. Lots of new stuff this morning. 1) Terminal panel (available in a panel and also as a dedicated Process module - similar to how the Adminer feature is set up) NOTE: It does not support interactive commands like vi, nano, apt, etc. DO NOT attempt to use these as they may result in you needing to restart apache. This is a bash terminal that lets you quickly execute commands on a server. In addition to normal commands like: ls, cd, cat, mkdir, rm, chmod, chown, etc, you can also do mysql command line calls which is very handy if you need to add a new user, create a mysqldump etc. Note that for mysql commands you need to issue them individually - you can't simply start "mysql" and issue commands from there - each call needs to include your username and password and the command to be run, eg: mysql -u root -p mypassword -e "CREATE DATABASE newtablename"; There is also an upload and download command, eg "upload test.txt" which will spawn a file selector dialog on your machine to upload that file to your server with the given name. It also has arrow up and down for command history as well as tab autocompletion of commands and file names. 2) Lots of new filterbox implementations @tpr has again put in lots of work to implement filterbox on the APIExplorer, Captain Hook, and PHPInfo panels - these will be super helpful to search through these complex panels. I have also added a ALT+F shortcut to get your cursor into the Find input for all these panels. Let us know how these new features work out for you. Cheers!

Not sure - I fixed so many bugs I can't recall anymore ? Maybe have a read through my Github commits - it might note this, not sure.

Are you using my fork: https://github.com/adrianbj/MarkupSEO/commits/various-fixes-enhancements or the main repo?

Perhaps I was too hasty in removing the live option, so maybe it will make a comeback now that LAZY is the default - just need some more testing to see if it actually helps with large dumps, and whether there are issues with the integrity of the data. So far from what I can tell, LAZY does an awesome job even with: bd($page, array('maxDepth' => 99)); or the shortcut: bd($page, [99]);

Thanks for spotting the left over LIVE reference. Actually between 2.6 dev and the releases version of 2.6 of the Tracy core, they actually changed LIVE to LAZY. LIVE still exists as a separate option but it still has some downsides. In most cases LAZY is better. You can read more about it here: https://github.com/nette/tracy/issues/344#issuecomment-468123490 Your data is still truncated because of the default maxDepth of 3 which is tweakable in the module settings. With lazy it's possible to have a much greater depth without performance issues so maybe I will up that at some point. You can of course still use db() or bdb() or bd($var, [10]) or one of the other combinations to up the depth. You'll find that with the new LAZY approach you can actually do a bd($page, [10]) and it won't cause an out of memory error like it would with Tracy 2.5. Hope that helps. If you have any more technical questions let me know, or perhaps address them to @dg at Nette.

@Pete - maybe you have already noticed this, but https://processwire.com/talk/discover/unread/ has black rather thank pink links.

Looking at one of my Process Modules, I use: 'page' => array( 'name' => 'admin-actions', 'parent' => 'setup', 'title' => 'Admin Actions' ), The parent has no slashes and will be relative to admin.

Your link to Cerberus is incorrect: https://tedgoas.github.io/Ce vs https://tedgoas.github.io/Cerberus/

They're not actually uninstalled - just do a Modules > Refresh and you'll be back in business with all modules settings as they were.

I assume you have uninstalled and reinstalled your module? This is needed to create the admin pages. Sorry if this is obvious and you've already done it.

Not much time to respond, but I bet the pages are created - check under Admin in the tree. It's probably a caching issue - do a modules refresh and logout and back in again. If you have Tracy installed, you can also just use the "Clear Session & Cookies" option in the PW Info panel. Hope that helps. PS I would definitely recommend using the module info pages approach - it handles everything for you, including uninstalling.

Thanks for pointing to that module @Sergio - I use it on every site. It would be hard enough for me to remember to change the page name to match a new title, let alone expecting a client to do it. Given that PW has the core Page Path History functionality, I rarely see the need to not change the name when the title changes.

Glad it all worked out - we've all done similar things ?

Home > Settings - color and icon stretching.

Soma and Robin S are missing their avatars - I am sure there are many more also.

Color for "ipsMessage ipsMessage_info" class is old:

Thanks Pete! Avatars are also stretched in the Notifications panel. Another thing I noticed is that all out locations have "Location" prepended - eg: "LocationBuckley, Wales"

bd() will work in site/init.php and site/ready.php - your OP code works for me in both of those files. You mentioned you had tested there already, so I didn't think about it, but I think @Robin S might be correct about what the problem is.

This is all @tpr's hard work - he has just added a search/filter implementation using his awesome filterbox.js - be sure to check it out and Star it! Note that in addition to filtering, if you hit "Enter" it will load the first matched file. Thanks again Roland - this is very cool!

Sorry, I wasn't suggesting setting everything up again - just a clean PW install with no modules, pages, templates etc just to see if it works. I imagine it will, but thought it might be a good sanity check in case there is some weird server setting somehow interfering - although I can't imagine what and you mentioned that you tried on your local dev as well and it still doesn't work.

I think you need to try disabling all autoload modules - Tracy's Module Disabler panel make this easy. If that still doesn't work, then try a fresh PW install just to rule out anything else.

What page are you viewing to test this? I don't think it should matter, but just curious. Other than that, I wonder if you can try updating to the latest PW version, just in case.

Those numbers are line numbers in the Page.php file. It suggests you are running an older version of PW. Page::render is a unique hook in that it actually comes from the PageRender.module file. Perhaps you could try hooking into PageRender::renderPage and see if that works.