szabesz

The use case is this: I have a local dev instance and I also have the live site and sometimes even another staging instance for testing another "branch". So same project, but different environments running different clones of the site. It does matter whether I make changes to the live site or to my local instance Since the admin area looks identical, it is easy to pick the wrong tab without noticing, especially around midnight

Interesting idea. Thanks for sharing!

Beautiful blog post indeed! However, you used the keywords: "for the current project only". I mean, I mixup the admins of the same project, so that is what I've solved with different admin theme colors. It would be an overkill to launch 4 Chrome instances for a project, 2 or three for another, and trying to tell the instances apart from my macOS dock would be frustrating. I also use other browsers too sometimes (for example here is Blisk I recently learnt about here, in the forums), although Chrome is my favorite for development so far.

For ProcessWire too How about a core module that supports it? Or at least a 3rd party module that is a joined effort and can be used in such cases by module devs?

+1 What happens when we click on it, anyway? It does not take us to processwire.com but... The proposed footer logo / current text version should be linked though.

Thanks for the idea, however, I used to use a prominent "corner ribbon" (eg https://codepen.io/eode9/pen/twkKm) but it was not enough, I did make the stupid mistake even thought it was big and red. Maybe its just me, I dunno... The header bar is even bigger and more prominent when it is "sticky", so I hope that will do. BTW, I normally have Tracy turned off for the backend, it's only enabled when fiddling with admin hacks , and this sort of feature probably fits AOS better, I suppose.

I even made a bash script to hack it:

Maybe because of System Integrity Protection eg.: http://www.macworld.com/article/2986118/security/how-to-modify-system-integrity-protection-in-el-capitan.html The mac I use for development is still running Yosemite, so I have not yet tried to apply this change on El Capitan. Note, that I use this change for wp-cli too (so, still on Yosemite).

The cause of the error was this "N98 will be trying to use your Macs native PHP which isn't configured for MAMP's MySQL resulting in the database errors." N98 is a phar file, just like wireshell. This worked for me: Change directory to /usr/bin cd /usr/bin Change the name of the native php to keep a backup (just incase) sudo mv php php.old Create a symlink to your php version sudo ln -s /Applications/MAMP/bin/php/php.[VERSION]/bin/php php You can redo this, so you might want to try it just to see what happens.

@Soma I used to have a similar issue with Magento's cli tool: https://magento.stackexchange.com/questions/26001/how-can-i-get-rid-of-all-the-various-database-related-erros-of-n98-magerun

Wow I will try it out for sure. As for the path, well, I do not think we have other viable options than using this path, so let's go for it, maybe with an additional subfolder to keep things organized, such as: /site/templates/aos or /site/templates/AdminOnSteroids which is longer, but more concise than "aos". About the color issue: I was just thinking about something like this (sorry for the actual colors, it is just an example...): #masthead, #branding, .main-nav-toggle { background-color: red !important; } #ProcessPageSearchQuery { background-color: darkred !important; } I do not want to recolor the admin, the WP part of the comment is just an example I'm familiar with. Changing the head is just enough for the use case I've outlined. But with the new admin.js and admin.css feature one can easily do this.

@bernhard Thanks for the link to the topic! I skimmed through Ryan's replies and the only thing that seems to matter is this: " I do think the software name ProcessWire, version number and copyright should always remain in the footer of the admin at least." I agree, I never wanted to remove these Also, I always educate my clients and teach them the name of the underlying system(s)/pieces of software they use.

I would also like to join the feature request club This topic reminded me of what I currently do in WordPress development: Besides being able to identify a site, it is also a good thing to tell apart the various instances of the sites we have (development, staging, live version, etc...). In the case of WordPress I use wp-cli to automatically update the site admin's color (the so called "Admin Color Scheme" setting), so that live sites are always in red, dev sites are in blue and staging sites are in purple. In the past, it happened to me that I worked in the wrong admin.... but with this skin changing trick, I'm far less likely to make this mistake again. Now back to ProcessWire My idea is that we could set a value in in config.php, such as $config->adminHeaderColor = #FF3935; which is used by AOS to change the background color of the header. Thanks to AOS I apply sticky headers, so this color indicator could be a strong one. BTW, here is another related feature idea: it would be cool if we could change the ProcessWire logo easily with AOS, replacing it with the client's logo.

Sounds pretty cool! Thanks.

@Speed I have MAMP Pro so I do not know if it works (also, it is an old post) but you might want to give it a try: http://jonathanmh.com/using-virtual-hosts-with-mamp-free/

+1

Welcome to the forums @tiefenb! more about urlSegments: https://processwire.com/docs/tutorials/how-to-use-url-segments/ https://processwire.com/api/ref/input/url-segment/ Have fun with ProcessWire

TracyDebugger also has validator support

Same here.

I haven't yet used the module, but I'm sure sooner or later I will, so I thought I should I share what I think about this part of your question. Personally as the developer/superuser I need the possibility to edit anything that generally does not break the site. Since this is not such a feature, I think only non-superusers should be restricted, but even this restriction could be optionally disabled by the superuser, at least for a given user role specified by the dev/superuser. Lots of small sites use at least three user role/group levels: Superuser-Editor-Guest where superuser is often the developer itself, and editor is the client. At least, this is the case with most of my sites. My clients do not want to touch things that might break the site, so they ask me to "hide" those settings.

I have just checked in Safari 9.1.1 and it is like your screenshot. It might be a CSS/JS compatibility issue, some sort of edge-case situation that might be hard to track down, I suppose. Anyway, after I update the viewport by resizing it, the background pops into place.

Strange issue, indeed! It seems to be ok in my Chrome though. However, it is such a "strange desing", that it is hard to tell whether what I see is intentional or not. At least the backgoung and the footer look ok.

I'm asking out of curiosity; did you also try Chrome's "Empty Cache and Hard Reload" feature? e.g.: http://www.thewindowsclub.com/empty-cache-hard-reload-chrome I found that Chrome often needs it in similar situations to yours.

I did not remember correctly... This line and its comment changed form RewriteRule "(^|/)\." - [F] to RewriteRule "(^|/)\.(?!well-known)" - [F] but still, "probable change" is always reported anyway.

One more thing to add: I did see an actually change to .htaccess a few weeks ago, but it was just some changes in some comments if I remember correctly, so no actual change in the way things work. However, this was a change, so it should be considered as such. But it does not really matter as long as "probable changes" are always reported for some reason.