szabesz

I have already upgraded to MAMP Pro 4 so I cannot be of much help here, but you might want to know that it is easy to "turn on" ImageMagick with MAMP Pro 4: EDIT: I forgot to mention that it is MAMP Pro 4 I use...

Swithcing to "selector arrays" might help to workaround this limitation: https://processwire.com/blog/posts/processwire-3.0.13-selector-upgrades-and-new-form-builder-version/#selector-engine-array-support

Thanks @Macrura for the info. I can live without such a module, but I see that it can be helpful in order to simplify things so I might start using it as it looks useful. I prefer modules being maintained, so I'm a bit cautious in cases like this, and that is why I'm happy to see you improving it

Hi @Karl_T You can find some troubleshooting tips by @kongondo here:

A short into by Ryan:

That is why in reality www stands for Welcome to the Wild West, and not for World Wide Web

It would be cool if the two of you could maintain this module. So far I've been hesitant to use it, but it's nice to see all the effort you are putting into it. Thanks!

The "official" blog post about this topic might also be of interest: https://processwire.com/blog/posts/making-efficient-use-of-fields-in-processwire/ True, the word "performance" is not even mentioned in it, but I guess this is because this is not really about optimizing performance too much. Optimizing database access by means of proper usage of API calls and cache should matter the most.

Thanks for the notes!

It's "funny" you chose the prefix "site_" because I always use it to prefix my identifiers in my "custom code" to indicate that it is my piece of code and not part of the core nor any other modules. Maybe I should switch to a less used word, such us "plat" or whateverv people would "never" use.

I created a request issue of this: https://github.com/processwire/processwire-requests/issues/78

+1 Example of replacing just the "content / innerHTML": <header id=my-header class=pw-replace-innerHTML> <p>First paragraph</p> <p>Second paragraph</p> </header> As and added bonus, this way any additional attributes the original ("to be replaced") <header id=my-header... has would be kept, so there is no need to repeat attributes all over the codebase which is hard to track and modify later on.

Ah, I see you did search...

Hi, did you search the forum? This is a question the comes up quite often: https://www.google.hu/search?q="it+appears+to+be+forged"+site%3Aprocesswire.com%2Ftalk&ie=utf-8&oe=utf-8

Maybe there is some confusion here. There is a topic discussing it:

Er, well - maybe, but only the stable branch

If it does not take off then why not? However if it does, I do not even want to be nearby... I do NOT trust software as I've already seen some in operation

Thank you! I've been missing it

This should be the keyword here. Also meaning a related API dedicated to support custom configuration options as well. No one likes to reinvent the wheel I guess, so some sort of "sub-theming" or better yet transportable settings and customizations would be nice to have instead of two or more completely separate admin themes.

How many admin themes are we going to have? This is not clear to me. We can expect UIkit 3, that's great However – just as I stated above – I'm a bit concerned about seeing people working on different admin themes instead of joining forces... I might be misunderstanding something here, I dunno.

May I ask why? The readme says: "Obtain a fresh copy of ProcessWire 3.0.51 or newer"

Sure! But the "main feature" of AOS is that is has on/off settings for each feature it implements. Anyway, I find it hard to see that having "three or four" admin themes around is better than a single but configurable one. You suggest modules to modify the admin theme by module developers, but which one when there are more than one? @tpr had to put some extra work into his module just to support the current two. Will he has time to support even more? Or anyone else, for that matter? Why not dedicate our time to only one, but a configurable admin theme, rather than spitting out "a lot", trying to customize them via modules later on? I might be wrong here, but this is how I see it at the moment.

Ryan says in his new blog post: "For instance, if you like a 2-column layout (like Reno) rather than 1-column layout (like Default) then that's a simple matter with the built in grid system. Nothing is set in stone, and our focus is on establishing the system to provide the path and flexibility for it all." also: "So what I've been doing here is coming up with a basic admin theme profile that the skilled designers in our community can then run with. My hope is this will be a collaboration where we'll come up with the best admin themes anyone has ever seen for any CMS. As a community, we'll want to select one or two that we can also bundle with the core in ProcessWire 3.1 as well." Well, +1 for a sidebar, but even better to have a setting that moves the menu from the top navbar to the sidebar and vice versa

That is why I wrote the above. Some instructions are very important all the time, some (lots...) can be hidden though when no longer needed. @tpr had to "hack" a lot of things just to realize a lot of features of AOS that will propaply break with the new theme. Generally true of course, however, most AOS users use most (and definitely not all) the features of the module, which boost productivity.

It might be obvious but I would like to point out that this would be the right time to implement most (if not all ) of the features of AdminOnSteroids which means at least a built in admin theme settings page to customize things to our liking, similar to AOS. However, there are features in AOS which can even be made better when implemented as integrated parts of the admin theme, such as "hiding"/revealing the Descriptions and Notes of fields. Having Descriptions and Notes around is extremely useful, but only in "development mode". When things are set up, they just take up space, distracting navigation and focusing, so I generally "hide" them by AOS (turning them into tooltips), but oftentimes I disable AOS, just to be able to skim through them quickly. Enabling/disabling AOS is not the best solution, because I loose all other functionalities of the module, but a native admin theme feature like this would only switch the relevant option of the admin, not all the others all at once. This can even be taken to the next level by being able to specify it on a field-by-field basis. The above mentioned example is just one, AdminOnSteroids is full of handy-dandy goodies that could boost the new admin theme a lot if implemented in an integrated manner.