horst

We all have had those days already! ? Please, can you set your thread title to show [SOLVED]? (simply edit your first posts headline), TY

There must be at least a log file called image-sizer with an entry for the admin thumbnail. And with a recent PW version (3.0.190) your original image is behaving fine here. So, it must have to do something with your setup, - settings for image field, modules that may interfere, etc. (!)

What exactly have you found in the logs? Where is the decision made to declare it as invalid? On uploading / adding, resizing? Is there the correct thumbnail already in your screenshot? How does it come that this one is created?

Ok, then MSPaint has generously corrected something in the original photo what GD is not able to tolerate. Do you can enable and use ImageMagick on that server? Maybe this is more tolerant then GD.(?)

Have you looked into the error-, exception- and messages logs? Maybe there are also logs for image processing. Please turn ON debugging ($config->debug = true;) in your site config.php before you do another try and then look into the logs for some hints.

Hey, welcome to the forums. Does your images field have some settings in regard of min- or max- sizes? (width, height, filesize, etc.)

Great! ? OMG, when reading your last answer, I finally got that GIT is used (responsible) for the merging-magic. Ok, that makes it look to me in another light. ?️ The whole time I assumed that there (at least additionally) must be some sort of importer in the CMS which has to deal with all the heavy stuff (conflicts and edge cases, etc). But now, its all good. ?

+1001 ? And my first request is, to start with TDD (Test Driven Development)! I can share the basics (or a starting point) for that, means I've a small and comfortable to use setup ready for that. Would need to write a short documentation / explanation, on how it works and should be used. +1 ? -10 ?

Many thanks @MoritzLost for the detailed explanations, (and the lowered down expectations of mine ? ). This makes all sense to me. Especially the point B) with the merge conflicts. If I have gotten that right it is not doable in a fully automated way (without interaction) with scenarios like: Developers A B & C start at the same time with the exact same state of the main branch, (the branch of truth), to develop new features or modify existing things. Developer A renames 2 fields, delete one field and create one new and after 2 days, his work is reviewed and merged into the main branch. When Developer B or C now want to merge their new branches after 3 or 4 days, they have the 2 old named fields and the deleted one staying in their branches. Some of that can or will lead into conflicts or inconsistency. The automated merge should not recreate the deleted field from Developer A, and so on. So, in conclusion, this automated static declarative update systems needs also a lot of discipline, consultation and interaction between the developers and with the merging / migration system. This implies that the larger the development team, the smaller the advantage of automation. Of course, the versioning through the YAML files, etc. remains unaffected, regardless how far the team will scale. But yes, somewhat reduced expectations. It sounded here before as if one must only lean back and everything goes by itself, fully automatically. ?

Hhmm, I do not get the differences between "you probably can't wipe out all fields since that would remove the database tables" and "remove fields that aren't in the config". ? And what is with the content in your previous example, (switching between your working branch and reviewing a coworkers branch). It seems that is not within the systems config dump, or is it? "In Craft, there's a clear separation of concerns between config and data. The config is tracked in version control, data isn't." When your coworker has implemented a new blog section, aren't there any new pages with content in his branch then? What comes to my mind with your example are mainly two things: A) The simpler one is: In PW I can do this (switching complete systems for reviews force and back) by simply switch the whole database instead of static config files, then I have everything whats needed for my coworkers branch, config AND content. And nothing is lost when I switch back the DB. So, where is the benefit with the proposed static config files system? B) The second thing, that's where I really hope is the benefit in, but what I yet haven't grasped is: How does it handle a migration of your dev work into the main branch and then one of another coworker and then the blog-implementation, and then etc, etc. ? This cannot be done by adding missing things and remove something from the main system what is not existing in a single branch work. Or can it? How does this function?

Just a try to understand this in regard of PW fields and templates: Would this go in a (yet simplified) direction like automatic write down *ALL* fields and template config into a file (or 2 files) for the export. And on the import, first wipe out all existing (current) config and restore / build the given state from the 1 or 2 files?

Hi @kongondo, for me it seems you pretty precise nailed it down! ? #1 is about prototyping #2 is a simple OneWayDeployment from dev to production, or dev to stage to production, but based on automatic exported text files from PW. #3 is about a deployment fully automated based on static files that describe somehow a start and an end for a deployment. This should be able to be rolled force and back, and even in a none linear order. The number 3 is what you want to use in a middle or large team of developers. It should make them able to use different states, maybe like with parallel git branches. And ähm, that's only how I understand it. ? EDIT: and yes, it is confusing to me too, because it seems that no one really has this differences, (that only reflect the different workflows and personal preferences) on the radar. ?

I'm not sure if I correctly understand what you want to track and how, but there is this module that may provide what you are looking for: https://processwire.com/modules/process-changelog/ Besides a paginated logpage in admin it also comes with an additional RSS feature:

FIELDS first! TEMPLATES second! CONTENT last! Even if you want add two new templates at once with a family relation like parent <>child, you paste in the JSON on the import site, it tells you about the conflict after inspecting. The solution is simply to run the import twice (two times). That is already supported by the importer.

You definetely should! ? Have a look at the Screenshots and its 100% save to:

Not tested, but Whats about the php function trim()? I would trim <p> and </p> from your fieldcontent. (sorry, onmobile)

https://www.google.com/search?q=site%3Aprocesswire.com%2Ftalk+RockSEO doesn't show much, but Rock(XYZ) indicates that it is a module from @bernhard (Bernhard Baumrock) ? EDIT: Oh, @Guy Incognito has beaten me! ?

+1 +1 Could be a good first (or next) step towards automated file based migrations with rollback feature! ?

@Erik Richter Which modules are active in that site?

Wich PW version is this site running on? Or was it running on 10.01.2022?

@donatas Hi, can you share your code for line 442 ?

How do you process the input? $sanitizer in use? If so, wich sanitizer method? You can debug the input directly before any processing with the raw $_POST or $_GET super globals of PHP to see if there arives more then the 246 chars. (And then go further step by step)

+1 ??

ATM I simply use the manual export <> import function from PW for fields and template settings. Every time I also have to alter field and or template settings, I write down the timestamp on a pad of paper when I start to do so and then collect a list (on the left side) of all fields I touches in the next time until deployment, (and on the right side I collect all template names).* When I'm ready for deploying, I may or may not shut down the live system for a short amount of time, depending on the amount of changes, then collect from the DEVs export selector all needed fields, copy the export json and drop it into the targets fields import field and proceed. Next step is the same with template changes. There is no need to shutdown a live site for long time. Mostly when I had large deployments, it was closed for one hour, but most of the time I do and have done those db migrations without any maintenance mode, because most of my sites uses ProCache. If it really would matter, I can prime the cache by crawling the site once before starting to deploy. It is not comfortable and also not the best I can think of, but it's not nearly as uncomfortable as described by @bernhard? Using these functions is not nearly as error prone as manually writing EVERYTHING into one schema or another for every field and template change. Noting everything by hand is not error tolerant for typos, I might forget to note a value, a change to a template, etc. All this is avoided by simply copy-&-paste ready generated JSON directly from PW. No typos, nothing forgotten, nothing added. Not perfect but for me much faster, easier and safer than writing everything down again by hand. PS: * In case you are not sure if you have written everything down on paper, you can generously include additional fields or templates in the export. In this case, it is better to have more (or even all) than too few. All unchanged settings will be recognized by PW during import and will not be processed further. ?

Hi @Didjee, unfortunately you are right. My old code no longer works. ? I have dived into the issue and filed a github issue with a possible fix. So hopefully Ryan soon will find time to look at it. ? If you like, as a workaround you can place my new suggestion into the file wire/core/Pageimage.php instead of using the current webp() function there. /** * Get WebP "extra" version of this Pageimage * * @return PagefileExtra * @since 3.0.132 * */ public function webp() { $webp = $this->extras('webp'); if(!$webp) { $webp = new PagefileExtra($this, 'webp'); $webp->setArray($this->wire('config')->webpOptions); $this->extras('webp', $webp); $webp->addHookAfter('create', $this, 'hookWebpCreate'); } // recognize changes of JPEG / PNG variation via timestamp comparison if($webp && is_readable($webp->filename()) && filemtime($webp->filename()) < filemtime($this->filename) ) { $webp->create(); } return $webp; }