adrian

And if you want the height to appear after the title in the page tree, you can use the "List of fields to display in the admin Page List" setting on the Advanced tab of the template's settings. And if you want to go even further and convert cms to decimal meters, you can use a hook something like this: $this->wire()->addHookAfter('ProcessPageListRender::getPageLabel', function($event) { $p = $event->arguments[0]; if($p->template == 'tree') { $event->return = $p->title . ' ' . ($p->height_cm / 100) . " m"; } });

Just one thing to consider - it may result in some weirdness when both actual and relative versions are shown together, eg:

Nice one @Robin S !

For this need you should be able to import data from an existing SQL table into a Profields Table pretty easily - either via CSV with the Table CSV Import/Export module, or even with SQL. The other option might be to build a custom fieldtype that utilizes something like http://tabulator.info/ to connect directly to your existing table and manage its content that way. Would that be useful for your needs?

I actually like the way that @dg from Nette handles this - he uses the "adrianbj authored and dg committed" approach which I highlighted once before - this allows the committer to make changes to the commit, while still having the author recognized as the contributor.

This is really well explained! I sometimes end up with "Text w/ Image", "Text w/ graph", "Text with quote" block types which works and helps with getting the css styles around these blocks to work as expected, but it would definitely be nicer to have a way to make interspersed content cleaner. Agreed!

He had already built the site in PW (and had it running for over a year) and then rebuilt it as described - that's the reason I brought it up - it obviously wasn't clear enough that he could use PW effectively in the scenario he wanted. Maybe "hacky" isn't the right word - I do it a lot and have my systems down, but I thought perhaps it could be improved and be easier for those who want to do all frontend code in JS (which isn't me BTW). I appreciate all your comments around the security issues for this though and as always you have that as the highest priority, which is great - thank you! I guess it's mostly the ability to edit all the fields on a page, including those that require JS (like repeaters, image upload, etc) so that frontend users can edit their content (think complex user profile data etc). It's doable already, but it involves ensuring key JS files are included and some relatively complex API logic to get everything working correctly. A way to make this really simple could be very useful. Displaying event calendars - usually things like weekly farmer's markets, open mics etc I don't agree that it wouldn't make a difference - I know my needs are more complex than some users, but I've seen enough likes / replies to many of my GH issues to know that these things are affecting others as well. I think lots of users would like to be able to expand/collapse all items at once, but they don't know they can because the UI for it is so hidden ? I don't think it's an age issue - unfortunately I think it's always never quite felt right - in some ways I actually prefer the tightness of the default theme but it's look is definitely too dated. Thanks for taking the time to think through all my suggestions and minor gripes ?

Regarding @teppo's suggestion about a native external API - I know that we just lost one PW website to a JSON / GraphQL / Gatsby / React stack because the developer decided that was easier to do that than use GraphQL / Gatsby / React on top of PW. Personally I think his decision was misguided because now he is managing content in json files (he is the sole dev / content editor so he doesn't need an admin CMS), but I think he'd have done much better using PW for content management and generating JSON that can be pulled into the frontend. But maybe if PW had a native way of doing this, he might have stuck around and I am sure there are lots of other devs out there that ignore PW simple because they don't think it will let them use these modern frontend stacks. I do think an integrated javascript API would make lots of things much easier as it always feels a bit hacky to me getting PW data into JS - it would be great to have JS page object available on page load, but also to have a built in AJAX method to pull other PW data on demand. I do feel like we need to convince potential developers that PHP can work together with the rest of the tools they want to use - they don't need to use Node to integrate things. I am still baffled that companies are paying thousands of dollars a month for things like Contentful or ContentStack when PW can essentially do the same thing - I know there are other benefits to these services, but I find the downsides not worth the tradeoff. There are of course self-hosted headless CMSes out there, like https://strapi.io/ which has been around since the end of 2015 and has 32,000 Github stars and 600 contributors. I know you have constantly maintained that you don't care about popularity, but clients often do, and with good reason - they need to know that there are other developers out there to take over if needed. The other big thing for me is finding ways to make certain data queries more performant, perhaps with something like @bernhard's Rockfinder functionality built into the core so that we can pull large amounts of field data in a more performant way - we don't always need all the info contained in the PW objects that are returned by regular API queries. Honestly I haven't yet used Rockfinder in production - I've actually gone with custom SQL queries of PW field data to build up objects/arrays exactly as I need them, but some inbuilt methods for automating this (like Rockfinder does so well) would be nice. One thing I would like to see is a way to easily implement certain admin forms in the frontend - yes we can do this with the API, but having all the admin tools available in the frontend would have saved me a lot of time over the years essentially rebuilding functionality. Sometimes I can get away with the AdminBar module, but it's not always appropriate. If you want an idea for another profield, a properly working version of a recurring dates field would be awesome. Unfortunately the Recurme module just isn't a viable option - I do have it running in production, but it's not efficient and I have several hacky fixes in place. It's actually a difficult problem doing recurring dates well, but it is a common need for lots of sites and so a good implementation would be very popular. However, my biggest concern and bugbear has always been what some might consider little things, but these "little things" can sometimes cause lots of frustration - things like: https://github.com/processwire/processwire-issues/issues/550 - there are lots of other examples of these sorts of things that require hacky workarounds. It is much more important to me to find proper solutions for these than adding fancy new features. I'd also like to see the admin user interface tightened up - there are lots of areas for improvement and so this is just one silly example, but having the double-click to open/close all repeater items on the on/off toggle button is confusing and I think needs fixing. I have converted a local web dev agency to be exclusively PW (from Drupal), but whenever we chat, their main complaint is always the look of the admin - they feel it doesn't look modern and clean enough and makes PW look a bit cartoonish. Please don't take that as a personal insult - getting this right is difficult and in my mind take a very talented design person to get the details right - I can see the things that are jarring, but I am not good at figuring out how to make them right. I think this is really important in ensuring that PW continues to be something that we can convince clients is a modern platform. I do also think that the interface to RepeaterMatrix could be modernized. I am not a huge fan of fancy website builders, but I do think we need to find a middle ground between what RepeaterMatrix currently provides and the best of the new building tools out there, because eventually clients will complain that they don't have access to the shiny new tools - it hasn't happened to me yet, but I think that's partly because of the type of clients I typically have.

Can you post the image in question so we can test it, just in case there is something weird with it - even though I know you said it works sometimes.

Thanks @Robin S - should be fixed in the latest version.

Thanks for your input @horst - turns out this error is new to PHP8 because they changed the behavior of the shutup operator so that it no longer silences fatal errors. I have filed an issue for Ryan with a working solution here: https://github.com/processwire/processwire-issues/issues/1299

Hi @horst - not sure if this is your code or Ryan's, but thought I'd ask you first. I am seeing that error when calling resize on a GIF. It is pointing to line: 866 in /wire/core/ImageSizerEngineGD.php The second argument is returning 255. Perhaps the solution here: https://stackoverflow.com/questions/3874533/what-could-cause-a-color-index-out-of-range-error-for-imagecolorsforindex is what is needed. Any thoughts? Thanks, Adrian

They are custom fields (columns) added to the field_images database table. @Robin S - have you seen this module: Is this mostly what you are looking for?

Hi @ryan - it's been a great year for the PW core - thanks for all your hard work as always and very glad to hear that pro module sales are doing so well for you! In addition to the requests repo that @Robin S mentioned, there is also of course the https://processwire.com/talk/forum/5-wishlist-roadmap/ thread. I actually think it would be best to start with the issues repo and once those are all fixed, then move onto those two requests lists. Lots of user input has gone into those lists and I'd hate to see that effort ignored or pushed aside in favor of new suggestions. I have lots of new suggestions / ideas, but I think they should wait so your efforts can focus on outstanding issues first - does that make sense?

Brilliant - thank you!

Hi @teppo - Happy New Year. I wonder what you think about removing the "by " prefix from the username. I have a lot of users on one particular site and I often want to find a user by making use of the browser's autoselection when you start typing when a select field is focused. It still works as is, but it means I need to type: "by ajones" instead of just "ajones". Thanks for considering. Actually, on a related note, it would be nice to be able to limit the shown users to certain roles, or at least those that have admin page-edit permissions.

@ryan - looks like the presence of a support button is not dependent on there actually being a thread for a module, eg: https://processwire.com/modules/login-register/

Sorry I guess I am not understanding what you want to do. That module triggers module upgrades in one step and you could certainly call that code from anywhere.

This should help you get going: https://gist.github.com/joyrexus/7307312 Things like prevAll() will need to be done with a loop. Googling things like "prevAll in vanillajs" will provide you with examples.

@Sascha Nos - not sure your overall goal here, but take a look at: https://processwire.com/talk/topic/8410-module-toolkit/ which adds a batch upgrade button to Ryan's PW Upgrade module. Maybe you don't want to use it that way, but perhaps you can extract the code you need. Let me know if you need any help deciphering it - it's a bit of a mess ?

Sorry @ryan - I think maybe I wasn't clear - the "list position" I was referring to, is the position of the combo field in the ordered list of fields within the template settings. Once you have separately configured the position of all combo subfields, it doesn't matter where you put the combo field in the template field list. It's not a big problem - just an observation. Thanks again for making this possible!

Thanks @Robin S and @ryan - this makes Combo an entirely new beast - so much more powerful and flexible - thank you both for your persistence and openness to making this work. I do agree with Robin that the way the ordering is configured is not ideal - it could be very time consuming for example if you have a combo field with lots of subfields and you need to insert in images field right in the middle. I do agree with Robin though that it's definitely confusing looking at the order of fields in the template settings now, especially in the scenario where you have custom placed all of the combo's subfields. You have this combo field in the list is a position that really has no relevance anymore. BTW, I really like the fact that if you use the new Custom Form Placement option for every subfield, it completely removes the label/fieldset container of the combo field which I think is often a key part to giving this the flexibility it needs to be useful in a wider variety of use cases.

Hi @Dennis Spohr - thanks for testing all that. Would you mind posting a issue on Github so that @ryan can track this. Please include a link to this thread.

Perhaps it's worth trying the new: $pages->parents()->rebuildAll(); https://github.com/processwire/processwire/blob/d3b1ab2983108a0410f7c66997f0478e7f3e02e6/wire/core/PagesParents.php#L580 Obviously a DB backup before doing this is essential, or do it on a dev copy of the site.

What version of PW are you running? In 3.0.156 there were a bunch of changes related to page parents: I am wondering if these changes might help, or if you are already running this (or later version), if it was faster before?