adrian

https://github.com/processwire/processwire-issues/issues/1300

Great - thanks! Actually, I was thinking it would be an option in the modules' config settings so that we can completely exclude users with frontend roles, or the "guest" user as appropriate. But maybe an extra filter would actually be better so that those actions are still logged.

@monollonom - I think your simplified condition is fine. That was the first PW module I ever built and I am pretty sure I copied that condition from somewhere on the forum and probably didn't fully understand it at the time. And while I have updated the module considerably since I created it, that is one thing I hadn't really noticed as being unnecessary. I'll probably clean it up in the next version.

Hi @MoritzLost - thanks for the detailed report. Should be all fixed in the latest version.

For images added via the API, you need Pagefile::install This block from my CustomUploadNames module might be helpful in seeing how I handle admin vs API uploaded images. https://github.com/adrianbj/CustomUploadNames/blob/9c896717459d1674c8ca37731c8a6f79730436a7/ProcessCustomUploadNames.module.php#L92-L103 and you'll also see differences in the customRenameUploads() method below.

@ryan - another thing I'd like to see is the search functionality from this module: https://processwire.com/talk/topic/14354-fieldtypedatetimeadvanced-subfield-selectors-for-datetime/ incorporated into the core datetime field.

This is also really important to me - I don't always want the editors to have too much flexibility.

Glad I am not the only - I was intrigued by what I read, but that video was confusing as hell. Either way, I have never been a fan of what the Basecamp guys do, so I would definitely be hesitant for that reason alone - maybe an unfair approach to judging Hotwire because I am sure they've learned a lot since they build Basecamp. This sounds a bit confusing to me. I feel like we either need a separate decimal fieldtype, or maybe a FieldtypeNumber that has options for all the numeric types that MySQL supports. Of course we also have a separate FieldtypeInteger, so maybe it will start to get confusing if they are all combined into one Numeric type now, although I think it might be the ideal option, although I haven't thought through all the possible issues with this yet.

Thanks Ryan - this sounds like exactly what we need - it would be great if authors of all alternate theme modules could update to use this approach - currently they are all subject to getting behind the core themes in terms of functionality. I wonder though if perhaps it's time to set up a "base" theme that handles all the basic functionality / layout of the admin and have Uikit extend that. Of course the default theme and Reno could also be modified to extend it, although I expect doing that would be a waste of effort as I think most people are using the Uikit theme. Regardless, I do think it's time it became the default theme way one or another.

Not trying to diminish your request for this to be in the core, but just an FYI that AdminOnSteroids supports this. The other thing it supports which is pretty much the main reason I use it is so that the buttons show on full row hover - I can't stand using the admin without that feature - it reduces mouse movement but so much ?

I believe it's a technical step in the merge process. It's interesting because 4 years ago I posted a message to you (I'll PM you about it in a minute) about this and back then Github used this phrasing: "adrianbj committed with dg" but if I look at the commit I referenced back then, it has now been reworded as "adrianbj authored and dg committed" so it's the same technique, just differently named. I think this SO answer is helpful in explaining the ways this can happen when editing someone PR: https://stackoverflow.com/a/25327781/1524576

@Kiwi Chris - sorry, I didn't initially understand what you were looking to do. It sounds to me like the new Combo field is exactly what you are looking for. It dynamically adds/removes actual DB table fields as you modify the combo field's subfields, so it allows you to sort, group, query like you would with any regular SQL DB table. It is not at all like the custom file/image fields which are stored as JSON.

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?