szabesz

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.

It's a lot of code to dig through, so I do not have the time to analyze it but one thing I noticed is that I found values like these: class ProcessWire: const indexVersion = 300; // required version for index.php file (represented by PROCESSWIRE define) const htaccessVersion = 300; .htaccess: # START PROCESSWIRE HTACCESS DIRECTIVES # @version 3.0 # @indexVersion 300 index.php * @version 3.0 * * Index Versions * ============== * 300 Moved much of this file to a ProcessWire::buildConfig() method. None of these can be used to compare against the actual version. What am I missing? Anyway, the change detection does not work as it was probably intended to work ot it is useless in its current state. I just use a diff tool to see what actual changes there are, if any. If only version numbers are compared to each other, then the message of the module should not suggest that it has actually detected "possible changes". I can be mistaken, but this is what I have gathered so far.

Normally I upgrade by using the ProcessWireUpgrade module and I've noticed that 3.0.30 is the one that shows up as the latest version. Is that intentional? I've been having another issue with ProcessWireUpgrade and it is about index.php and .htaccess changes detection. It keeps detecting changes even when there are no changes at all. I've been using a diff tool to check for differences and usually there is none, but the module always reports changes.

How about any 3rd party modules that might "interfere" with the session handling? I know it is a vague idea, but if you have 30+ sites, you can try to compare them to each other in order to figure out what might cause the culprit.

Thumb's up! I'm not a GitHub guru, but it sounds like a clever idea. To tell the truth, I'm a 3.x only guy, but following your blogposts, I can see that you really take it seriously, and thank you for this! I've seen awful major version changes of other CMS'es/frameworks already, so I'm sure anything you will finally come up with will be far better than those.

I was thinking of this too. It is incredible what you have achived so far. You might want to charge for the module in the future. How about a light and a pro version? But psst! It wasn't me who gave you the idea