adrian

Just committed a nice little enhancement to the Adminer panel - it now loads the panel with the relevant table or row based on the current context. So if you are editing a page, it will load the row for that page. If you are editing a file, template, or viewing a module's config settings, it will do the same. If you viewing the main page list tree or the main templates/files/modules pages, these tables will be opened in browse mode. Probably not something you'll use that often, but because the Adminer panel doesn't load anything until you open it, I like leaving it activated as one of my default panels so I always have really quick access to view whatever is in the DB for what I am currently working on. Anyway, hope you all find it useful on occasion.

I would also say that it should also mention JS libraries, scripts, etc. No need for a plugin for a simple JS carousel etc.

@bernhard - I'd love to see something like this - this is exactly the skinning type approach that I think is needed for the PW admin. It makes so much more sense compared with creating new themes in most situations.

Try this link: https://sitemod.robin.nz/render/?url=https%3A%2F%2Fprocesswire.com%2Fnewsite%2F&css=https%3A%2F%2Fsitemod.robin.nz%2Fnew-pw%2Fmod-1.css

There have been a few recent comments about the text in various sections being too verbose - I'd just like to mention that I agree with this ? I am not totally sure I like @3fingers re-colored version, but one thought I had yesterday before I saw it was that I find it quite a harsh change going from the simple single blue color of the new site to the multi-colored admin panel in the demo. I am not saying that the website and the PW admin need to look identical, but I do think it looks so different that I feel like I am somewhere else with a different product. @3fingers version ties the two together, although I am wondering if maybe the admin should look more like the site by default? I am not suggesting any change to the admin immediately, but something to think about?

Hi Ryan, Not exactly sure how this would look or work at the moment, but what do you think about having the Tracy Console panel available on the demo site so that users can play around with the API. I am thinking of having some snippets in the snippet sidebar already saved so that they can load those as starting points / examples. Some examples would show using d() calls to return objects, but we could also have some with echo outputting actual HTML with PW variables embedded. Think of this as ProcessWire codepen / fiddle type feature. Obviously save operations etc would have to be prevented so they can't damage the demo site. On another note, maybe down the road users could have access to their own demo site like Wagtail does (https://control.divio.com/demo/get-new/wagtail/) where the user can actually edit page content and see the changes on the frontend - a little like the old lightning.pw Anyway, let me know what you think about the Tracy Console idea.

A few more thoughts: I feel like the Selectors page (http://processwire.com/newsite/docs/selectors/) needs to be more prominent. To me, this is more useful than the current "Getting Started" and "Tutorials" pages. Or at least, it should be a page that is listed on the Getting Started page. Speaking of the tutorials page, I don't like that most of these are external links - even though they are great resources, I'd rather have users see a centralized source of the best tutorials on the PW site itself. I don't like the pages that put the title next to the PW logo in the header, especially given that not all pages do this - I know it depends on what level page you are on (although not entirely), but I still find it a little confusing. I also don't think that the "Community" top level link should go anywhere. On the variables page, you have: "page() accessing as a function can be very convenient, when available." - how or why wouldn't it be available? I know, but new users won't. This one: $pages->wire('page') is actually quite confusing - again, I get it, but certainly never thought to use it like this and I think it would be really weird to do something like: $pages->wire('fields') I would say this option should not be shown. I also am not sure about showing: $this->page when on the very next line you state that: $this->wire('page') is more efficient - why would anyone want to user the former? Sorry for all the negative, but you know how feedback often is ?

I would go with the first image for the existing posts and then from now on you could make use of a "feature image" option.

Overall looking great. Just a couple of quick things - I'll try to dig in deeper later. I think The API examples using a mix of $pages and pages() is confusing. I would stick to one approach The demo site should be running the latest stable which is currently isn't I'd like to see a Github link on the homepage or preferably the footer for all pages. I think it gives an open source project legitimacy and advertising this upfront can be an important thing for swaying someone to look around further. On the site directory, is there a reason for the category order? I think it's especially weird that "Newest Additions" is second. Speaking of the sites directory - are you running a regular check on all these site (using @teppo's isit.pw) to make sure they are still powered by PW - I think it looks really bad for PW if a listed site has been moved to another platform. The "What you'll love" page is so long. I saw the TOC links at the top and didn't initially realize that they scroll down on the current page. It seemed link too much to look at - where do I start? This page (http://processwire.com/newsite/about/requirements/) lists PHP 5.4, but this one (http://processwire.com/newsite/docs/start/install/new/) says 5.3.8 still. At the bottom of http://processwire.com/newsite/docs/start/install/new/ you state: "See our download page for additional download and installation options.", so I think it should link to http://processwire.com/newsite/download/core/, rather than http://processwire.com/newsite/download/ I think the master and dev download buttons on http://processwire.com/newsite/download/core/ should show the version numbers Afraid I don't really like the blog page - I feel like the blocks are too confusing - I'd rather a more normal vertical approach and an image (when available) to go with each summary. I was surprised that Page Reference fields are not listed here (http://processwire.com/newsite/docs/fields/). BTW - I think that all docs needs to use "Page Reference" rather than just "Page" because in PW "Page" is already used so much. BTW - thanks for the link to Tracy from http://processwire.com/newsite/docs/more/

On some sites I actually have a "menus" tab on the homepage and in that tab there are two page reference fields: one for top menu and one for the footer menu. This way the site editors can easily adjust which pages appear where and none are shown anywhere by default.

Hi @breezer - this is a good explanation of the problem: https://stackoverflow.com/questions/13734224/exception-serialization-of-closure-is-not-allowe That link shows up as visited by me in google, so apparently I have come across this before but I don't remember the circumstances. I actually just removed two serialize() calls from Tracy. There is one remaining in the core Tracy package that is used when logging an exception. I am not sure if this is the reason you are seeing it or not though. Is this a new issue for you in 4.16.8? Do you have any serialize() calls in your code anywhere? Could you check in the Tracy logs directory (site/assets/logs/tracy) to see if there are exceptions logged. Does it help if you modify the getExceptionFile() method where the serialize call is made: https://github.com/adrianbj/TracyDebugger/blob/b195d6ac40e146891151ac7b56590ba34eb03f7b/tracy-master/src/Tracy/Logger.php#L136 - you could empty out all this method and just return true or something like that to help narrow it down. Let me know about these things and we'll go from there.

This should also work: strpos($input->url, $this->wire('config')->urls->admin) === 0 so long the PW version is after this bug was fixed

I don't think I found any problems with it, but I have also been using: strpos($_SERVER['REQUEST_URI'], $this->wire('config')->urls->admin) === 0

Small update to the "New Since" section this morning. It now automatically generates a full API data cache before any PW core system updates so there is no longer a need to have the API Explorer panel open before changing the core version. I also fixed a bug generating this when in the PW admin - it was working fine on the frontend of a site, but not the backend.

Glad you like it ? While I like your thinking here, I think it might actually be a better fit inside Ryan's API Explorer Pro module. My understanding is that he uses that to build the documentation on the website as well as being a module that users can install on their systems. I think because of the way I have written this for Tracy, working off an array of classes/methods/properties cached from the last version, I don't think I have much of a leg up towards what you are suggesting. I definitely think it's a good idea though and maybe worth a suggestion to Ryan here: https://github.com/processwire/processwire-issues/issues/759 Perhaps someone out there with Ryan's module might like to tackle adding this functionality?

What about putting it in the HTML placeholder attribute?

This is now available:

Happy holidays everyone! Here's a little present for the new year ? The API Explorer, Console, and File Editor panels now have access to the PW API data via a cache, rather than generating on-the-fly so those panels are now all much quicker after the first load after a core or module version update/install. This also means that we can now provide a "New Since" section in the API Explorer panel, which I first suggested over here. This shows you all the additions to the API compared with the previous installed version. In the screenshot you can see what's new since 3.0.117. If you want to get details about the changes from earlier versions, use the Process Version panel to change back to an old version (to build the cache of the old version), and then change back to the newer one. The Console and File Editor panels only cache the variables sections, so the list would be incomplete if you only had those loaded. I just ran this on the old PW master (3.0.98) and then switched to the current master (3.0.123) and this is what was returned - quite the changelog! A lot of refactoring went into this so that I could cache the API data in a way that I could compare so please let me know if you notice any problems.

Hey @tpr I have been seeing this a bit lately: Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in /site/modules/AdminOnSteroids/AdminOnSteroids.module on line 2622

Hey @tpr - thanks for figuring that one out ? A bit OT - I haven't ever used the language translation feature so maybe I am confused about something, but when I click the "Click here to build search phrase index" link, it takes me to the "Select File(s)" page so if I actually want to use the live search feature I then have to go back to the previous url. Back to the issue - I have made your suggested change and I can confirm it works here, but I do have to wonder if this is maybe actually a bug in the phrase-index generator or the code that loads the results - shouldn't it be the place where the entity conversion happens, because there must be other modules out there that will trigger this error as well. Do you think a Github Issue should be raised?

Thanks, the fix you provided looks to be working well. I have just committed it.

I can't see why that $p would ever be an integer - would you mind checking to see if it's returning a $page id or something else for me? It should be a page object. Thanks!

There are lots of shortcuts ? I think @matjazp was looking to have one in the Console panel. Yes I could make it a module config setting but if you make it the default then the "Clear Results" link it irrelevant (I guess it could be removed in this case), but then you'd have to use shortcuts to not automatically clear the results. Some time ago IIRC there were two buttons, "Run" and "Clear & Run" and no separate "Clear Results". I actually think that you had something to do with this change but I don't really remember why we went this way? Yeah, I agree the Tracy settings can be slow to load. Turns out the biggest issue is actually populating the DOM. If I simply collapse all the fieldsets it loads reasonably quickly. I used to have all (except the first couple of key ones) fieldsets collapsed, but I was convinced to change this, but that was some time ago and there were a lot less settings then. I wonder if I should revisit this? Perhaps I should collapse by default, but when following the cog/settings links at the bottom of a panel, then this would open up the requested fieldset. Maybe it also needs a toggle all at the top of the settings page for those who actually want to browse? Any thoughts?

Hey @matjazp - I don't really want to add another checkbox to the interface if we can avoid it, but I value your opinion, so I am curious why you would like this. I never use the "Run" button, or the "Clear Results" either. I just use the keyboard shortcuts - almost always the ALT/OPT + Enter combination (which automatically clears old results before running), and occasionally the CTRL/CMD + Enter combination if I do actually want to keep the previous results for comparison. Is there a reason you don't like the keyboard shortcuts, or is there some other reason I am missing that makes this new checkbox a useful addition?

Nice catch! It's interesting because many of the $sanitizer methods make use of the internal nameFilter() method which uses mb_strtolower. If you actually follow the cleanBasename method it goes through $sanitizer filename(), which uses name(), which uses nameFilter() which leads me to believe that it might actually be possible to just remove that that: $basename = strtolower($basename); line from the cleanBasename() method completely. I just tested this and it's actually pretty close - there are a couple of problems - one is the regex on #578 needs A-Z added to it. The other is that beautify doesn't get passed through to nameFilter() which is a condition for mb_strtolower() being called. Anyway, that was just an interesting excursion into what is actually going on and where ?