horst

<shameless advertisement>I use PIA with $image->contain("size=200"); It respects upscaling and weighten too.</shameless advertisement>

@lenoir Maybe, as a simple way, you also can add a select field near to the croppable image field and let the user select which format he want to be displayed on that page on the frontend.

Hi lenoir, the designer / developer decides which format is displayed at the frontend, as he embedds the API code for the output into the template files. For example, if you define two formats (landscape and portrait), the user has the possibility to select the relevant crop section for both formats, but in a regular / simple setup, the output is defined in the template files with $image->getCrop("portrait")->url at places where a portrait image is required. If you want to give the user the possibility to choose from different formats for one single place, you need a special setup with e.g. pagetable or the ProFields Repeater Matrix wrapped around the image field.

These subpages named home, etc, didn't they have a template called repeater_slider_repeater ? I'm not totally sure, but to a great extend, that the repeater items always have a template name with prefixed repeater_

and how does the rendered markup look like?

Ah, I think this is a bug, or at least it is not obvious for the user, how to define the template for a repeater. If you define a template, it checks if the current page has this template. I believe "home_final" is the template of the page that contains the repeater? The repeater item itself is a page too, but its template isn't "home_final". As a quick workaround: determine what is the template name of the repeater items and set this, (maybe additionally), into the fields setup. For example, if I have a repeaterfield named topmenu, I will find its items under Admin -> Repeaters -> topemnu -> ..., and their template is repeater_topmenu For the long term, i will see, if this can be done by the module behind the scences. But it will take some time that is currently not available for me.

<?php // only render output if there is something set in field json_ld_alternateName if(strlen($page->json_ld_alternateName) > 0) { echo " <script type='application/ld+json'> 'alternateName: '{$page->json_ld_alternateName}', </script>\n"; } I wrap "doublequotes" around the php string and use 'singlequotes' for strings within the markup. If you run into situations where you also would need doublequotes within the markup, you can use them if you escape them with a backslash: <?php echo "<p>A string with 'singlequotes' and escaped \"doublequotes\"!</p>"; // will output: <p>A string with 'singlequotes' and escaped "doublequotes"!</p>

Hi @Marty Walker, this seems to be new. So, just a shot into the blue: can you inspect settings in regard of adminThumb ($config->adminThumbOptions) in your site/config.php, and compare this with settings from the wire/config.php. Your site/config.php may have old settings from PW 2.7 that overwrites newer settings introduced with PW 3.0 to become unusable. (Maybe something that results in a thumb with 0 px height or width. If this doesn't help, it would be useful to see the markup (HTML-code) of that thumbnail.

@adrian: Ok, your solution wasn't present when Antti wrote the legacy module. Is it right to assume that getting the " $inputFieldInstance at line 190" failes and it does an early return here? If so, and if it works for you and @ukyo this way, I will push this to the Github repo.

@ukyo: have you changed back the first workaround, and then added this change as only one? Does this work and does it also create a crop variation just with or after the upload? Many thanks for your help here!

@adrian: this is taken over from the old legacy thumbnail module. But, if I remember right, it is also present in core file and image modules. I need to test this.

Maybe the setting is not relevant, but saving it one time before open the cropper modal? I need to test this.

Do you have opened the FieldtypeCroppableImage3 config screen once or never after install?

@adrian AH! Ok, that's what I have expected, but overseen. Sorry! @ukyo I don't think this is a real solution, because it should be able to create the crop and return a pageimage object. If you suppress the error so that it currently works for the upload, the crop will be created on the next request of getCrop(). But if there would be something other that fails, you wouldn't be informed and wouldn't get any crop variations. So this only can be a currrent workaround until @adrian has found the real issue. OT: @ukyo With that other issue you mentioned, it seems that you are the only one who has this. Please can you answer in the CroppableImage Thread my questions?

Which PW version do you use? (namespaced or not) or simply try this: $p = new Processwire\PageArray(); // added namespace $editable_pages = wire("user")->editable_pages; // use wire() $branches = wire("pages")->find("template=branch"); // use wire() foreach($branches as $branch){ foreach ($editable_pages as $edit) { if($branch->id == $edit->id){ $p->add($branch); } } } return $p; please play around with and without added namespace, but let in the wire() calls.

another thing: I haven't used the custom upload names module and thought to check if you have hooked before or after fileAdded Surprisingly, you hooked into saveReady?! When I want manipulate uploaded files, I always use something like this: // code snippet that belongs into the site/ready.php file: $wire->addHookBefore("InputfieldFile::fileAdded", function(HookEvent $event) { $inputfield = $event->object; // handle to the image field if(!$inputfield instanceof InputfieldImage) { // we need an images field, not a file field return; // early return } if(version_compare(wire('config')->version, '2.8.0', '<')) { $p = $inputfield->value['page']; // get the page, PW < 2.8 } else { $p = $inputfield->attributes['value']->page; // get the page, PW >= 2.8 | 3.0 (or only from 3.0.17+ ??) } $image = $event->argumentsByName('pagefile'); // get the image // now do something with the image or file ... });

On a side note: You cannot use - in your names, because - is the devider for suffixes in image variation names. Please change full-width to fullwidth or fullWidth! But back to your issue: I wasn't able to recreate it. What exactly have you done to install it? Passing in the class name here: Admin > Modules [ NEW ] -> ModuleClassName Which classname have you passed?

@adrian: the normal behave of CroppableImage is, that it creates any requested crop variations on upload. (To be more precise: just after upload, but before or during markup for the Inputfield-Item gets rendered) It does it in FieldtypeCroppableImage3::getCrop($suffix) // (exact the function that fails here!), so you need to debug this further: ... InputfieldCroppableImage3::getCropLinks ($pagefile) FieldtypeCroppableImage3::getCrop ($suffix) // called from InputfieldCroppableImage3::getCropLinks ($pagefile) in line 139 getCrop() is a hook event, defined in FieldtypeCroppableImage3 init(), line 44. It starts at line 172. You should look (step by step, if possible) where it has an early return, without creating and passing back the expected pageimage object. What part is failing in the process, when trying to get: $suffix // 175 $inputFieldInstance // 190 $templateName // 197 $cropSettings // 198 $img // 220 $imgPath // 222 $isReady // 262 ( <= is it this? // do we have a file? : is_file($imgPath). - So, if yes, the values above, starting at line 221, $img->basename seems to be not updated with the changed ones from your module?? hope this helps a bit. If you find out what failes, we can look further what is the best way to fix it.

Ok, thanks for clarification. No time here to investigate much further, have no free dev env here atm. Looking into the code, I believe this is the chain: InputfieldFile::fileAdded ($pagefile) // line 460 InputfieldImage::fileAddedGetMarkup ($pagefile) // line 490 InputfieldImage::renderItem ($pagefile) // line 522 InputfieldCroppableImage3::renderButtons ($pagefile) // line 56, coming from InputfieldImage::renderItem line 545 InputfieldCroppableImage3::getCropLinks ($pagefile) // line 74, calls many properties from $pagefile (!) Debugging that three vars ($pagefile, $suffix, $pagefile->getCrop($suffix)) around line 128, like Adrian said, would be useful.

@ukyo: what I tried to say is, that CroppableImage3 is an extention of the core imagefield and it incorporates all stuff related to uploading as is, without making any changes. Therefore, maybe it would be interesting if you have the same behave when trying with a regular core imagefield, or how that differs.

Yes, thats exactly what I mean. If one specify a fixed timestamp and this point is passed, I have added a delay to the current time and passed that back. As you said, this is the same as the delayed approach, but with little overhead. This can be simplyfied: send header with fix timestamp if it is in the future, otherwise send header with delay in seconds. Maybe, the delay should be configurable too?

Many thanks @adrian, now I'm back again in regular update process with the module. Yep! --------------------- I think only search bots will act according to retry-after. I have read on Googles advices on how they like to see handled maintenance mode for already indexed sites. And it was a 503 with a "retry-after" . If the estimated timestamp is passed, I added 60 minutes to the current time and sends this. Maybe, you can add this to the explanation, that one can check "send retry-after" but without a fixed timestamp too? This way we have enough possibilities, I think.

On a site that is always protected, it simply doesn't matter. But on a site, where I regularly only use some single protected pages but a big part is publicly accessible, there it is better to use SEO friendly headers when closing the whole site. It is important for sites that are already indexed, and temporarily are not accessible. That's why you thought it belongs to Petes module. But when I already have installed ProtectMode and it can close down the whole site, I have maintenance mode already, or not? Maybe best solution would be to offer both methods for the root page? Radio or something else for: protect | maintenance, plus a datetime via showIf for maintenance?

I think, sending a 503 and "retry after" should be done everytime if the whole site is closed / protected, regardless if you call it protect mode or maintenance mode. This is important for SEO. I think both of the modules, yours and Petes, should do that by default, when the whole site is not accessible for SearchEngines. (just my 2cents)

Yes and no. You cannot add it to a module config, but you can create a Processmodule with its own view page. There you can use an imagefield. https://processwire.com/talk/topic/8359-adding-image-or-file-field-to-a-module-configuration/ not full target, but a good starting point