Robin S

Thanks, I discovered this myself while I was experimenting yesterday, but it seems less than ideal for a couple of reasons. 1. When you do this, it seems that the image is first downloaded to your local disk, then uploaded to the site. This makes it unnecessarily slow for larger images or on slow connections. 2. The filename of the image is not preserved as per the original. On Windows Chrome at least, every filename gets "_1" appended to it. But on the positive side this approach does allow for client-side resizing. I had a go at a module that allows images to be added to a field via pasted URLs: I had a few concerns about the approach because the page and image field are identified by values that could potentially be manipulated client-side. But I've included some checks that hopefully mitigate this. Another niggle is that the API method $page->images_field->add() is surprisingly relaxed about what it will add to an images field. It doesn't seem to do any validation against the field settings or even disallow non-images from being added to an images field. So all the validation must be done independently (@Macrura, this might be something that affects your module too). I think I've accounted for most things, but if you guys will take a look and let me know if you spot any potential issues that would be great. Because the browser is not involved in the upload, no client-side resizing is possible but is done server-side instead (for max width/height settings).

Add Image URLs A module for ProcessWire CMS/CMF. Allows images/files to be added to Image/File fields by pasting URLs or using the API. Installation Install the Add Image URLs module. Configuration You can add MIME type > file extension mappings in the module config. These mappings are used when validating URLs to files that do not have file extensions. Usage A "Paste URLs" button will be added to all Image and File fields. Use the button to show a textarea where URLs may be pasted, one per line. Images/files are added when the page is saved. A Pagefiles::addFromUrl method is also added to the API to achieve the same result. The argument of this method is expected to be either: a URL: "https://domain.com/image.jpg" an array of URLs: ["https://domain.com/image1.jpg", "https://domain.com/image2.jpg"] Example: // Get unformatted value of File/Image field to be sure that it's an instance of Pagefiles $page->getUnformatted('file_field')->addFromUrl("https://domain.com/path-to-file.ext"); // No need to call $page->save() as it's already done in the method Should you have an issue using the method, please have a look at the "errors" log to check if something was wrong with your URL(s). WebP conversion The core InputfieldImage does not support images in WebP format. But if you have the WebP To Jpg module installed (v0.2.0 or newer) then any WebP images you add via Add Image URLs will be automatically converted to JPG format. https://github.com/Toutouwai/AddImageUrls https://modules.processwire.com/modules/add-image-urls/

You would think this would work, but if you test it I think you'll find that individual keys set like this have no effect. However, Ryan recently alerted me to this working alternative for setting individual keys: $config->imageSizerOptions('cropping', 'north');

That would be fine, but how do you add an image to an image field via a URL? I feel like I've read something here in the forums about doing this but looking at the image field interface I can't see how it's possible. There is only the "Choose file" button for uploading an image and the drag-and-drop zone.

Does anyone have any tips to share for moving an image from one image field to another on the same page in Page Edit? I know it can be done with the API but it seems like there should be some way via the admin interface. Like adding an image to an image field by pasting a URL - is that possible via the core or a module?

One button in the footer is expected - you are appending the rendered button to the Lister output after all. So there is just a single unexpected button being added. I think this is because your execute() method is called twice, once when the page is first rendered and once in an AJAX request from Lister. So you can make the rendering of the button conditional on it not being an AJAX request. $pl = $this->modules->get("ProcessPageLister"); $out = $pl->execute(); if(!$this->config->ajax) $out .= $btnAddNew->render(); return $out;

For a repeater field named "image_tags" in the "home" template, setting the tags list for an images field named "images"... // Save repeater titles to images tags list $pages->addHookAfter('saveReady', function(HookEvent $event) { $page = $event->arguments(0); // For the home template if($page->template == 'home') { // Get a string of tags from the repeater item titles $tags = $page->image_tags->implode(' ', 'title'); // Get the images field $images_field = $this->fields->images; // Set the list of allowed tags $images_field->tagsList = $tags; // Save the field $images_field->save(); } }); The titles of the repeater items will need to abide by the rules for image tags, so no spaces allowed.

Welcome to the forums @adiemus The description field is named "description" and you can include it as a subfield of an images field in your selector. So for a repeater field named "repeater" containing an images field named "images" your selector would be something like: $matches = $pages->find("repeater.images.description~=foo");

@drjones, you could add a "sort_name" field (hidden perhaps) to your template to store the number with leading zeros added. You would populate this field in a hook to Pages::added in /site/ready.php $pages->addHookAfter('added', function(HookEvent $event) { $page = $event->arguments(0); if($page->template == 'stick') { $page->setAndSave('sort_name', str_pad($page->name, 8, '0', STR_PAD_LEFT)); } }); Then you would use the sort settings of the parent page to sort its children by sort_name.

This is a test for if only a single template may be used for the new page. PW uses a hidden field for template in this case.

Despite Soma helpfully telling us we are all wrong, the code I suggested in that thread works for me: So you set up a field in each PageTable template to hold some reference to the container page - in the example below I use an integer field for the page ID, but you could use a Page Reference field instead. You would set the field to hidden so users do not see or change it. But for demonstration purposes I have left the field visible and also show the value in the PageTable columns. Note that the value is only set when the PageTable field does the AJAX reload (when the modal closes), so the value is not available when adding a new page to the PageTable until the modal is closed. In /site/init.php $wire->addHookBefore('InputfieldPageTableAjax::checkAjax', function($event) { $field_name = $this->input->get('InputfieldPageTableField'); // Just for this PageTable field if($field_name !== 'test_pagetable') return; $page_id = (int) $this->input->get('id'); $item_id = (int) $this->input->get('InputfieldPageTableAdd'); if($page_id) $page = $this->pages->get($page_id); // $page is the container page if($item_id) $item = $this->pages->get($item_id); // $item is the PageTable item // Set integer field to $page->id $item->setAndSave('container_page_id', $page->id); });

It just so happens that there is... Templates: Child Pages You could use this in conjunction with the hook below, which will use the template context for title label, description and notes if the number of allowed templates has been restricted to one: $wire->addHookAfter('ProcessPageAdd::buildForm', function(HookEvent $event) { $form = $event->return; $template_field = $form->getChildByName('template'); if($template_field->type == 'hidden') { // Only one template is allowed for this new page // Get the template $template = $this->templates->get($template_field->value); // Get the title field in the context of this template $title = $template->fieldgroup->getFieldContext('title'); if($title) { // Set the properties of the 'title' inputfield $title_field = $form->getChildByName('title'); $title_field->label = $title->label; $title_field->description = $title->description; $title_field->notes = $title->notes; } } $event->return = $form; });

For some inputfield visibility constants it is too late to set them at inputfield render. For Inputfield::collapsedHidden, Inputfield::collapsedNoLocked and Inputfield::collapsedYesLocked these are handled by the InputfieldWrapper class. I've found that a good method to hook for setting the visibility of fields in Page Edit is Field::getInputfield. This example is for /site/ready.php but easy to adapt to a module context: $wire->addHookAfter('Field::getInputfield', function(HookEvent $event) { // Only for ProcessPageEdit if($this->page->process !== 'ProcessPageEdit') return; $field = $event->object; $inputfield = $event->return; if($field->name == 'proj_code_folder') { $inputfield->collapsed = Inputfield::collapsedNoLocked; } });

Are you sure this is necessary? When adding a new page under a parent that allows only a single template for children, I find that any changes made to the title field in template context (e.g. changing label or description) are automatically applied.

Another option: set $config->debug = true in /site/config.php (which is a good idea in general while developing a site) and then hover the inputfield collapse/expand icon in Page Edit.

Ah, good find, thanks. Fixed in v0.0.8.

Yes.

Hi @jaro, I've been having a look at the Repeater issue and the BreakRepeaterFields demonstration. Interestingly, the issue is not that fields are copied from one repeater to another. It is that the module interferes with the listing of fields when the repeater field settings are viewed in ProcessField, causing the fields of one repeater to appear in the AsmSelect of another repeater. So if you check the database the fields associated with each repeater is actually correct despite the incorrect listing shown in ProcessField. But if the user then saves the field in ProcessField it is at this point that the associated fields become incorrect. Could you explain why the module needs to hook ProcessPageView::finished? This method fires on every page view, front-end and back-end. But most of these page views will have no connection to field settings or template settings changing. Instead of hooking this method, couldn't you hook only methods that are related to field and template settings? So some method in ProcessField and ProcessTemplate? And also, the module is looping over all fields on every page view. Could you focus in on just the field that is being edited? So when field1 is edited in ProcessField, just export the data for field1 rather than looping over every field. This would avoid the situation where the data for repeater2 becomes involved when editing repeater1. I should say that I've just had a brief look at the issue so far, so there might be good reasons why the module does what it does.

It would be good if PW did this by default on module installation. Maybe there is some downside but I can't think of any situations where you want the module config data to look populated (by setting default inputfield values) but not actually be populated. Default values could/should still be set in the construct method so there wouldn't be any notices necessarily. But if the config data was removed from the DB then the config page would appear empty despite default values still being used, which is a different kind of misleading I guess. I'll ponder it some more.

You don't have a proper PHP opening tag here: <? // ==== Processwire Multi Instance ===== // $pwpath = "/path/"; $pwurl = "https://url.example"; $pw = new ProcessWire($pwpath , $pwurl); ?>

@Federico, the module seems to be working for me as expected. So I will leave the module as is for now unless I hear of others having problems with fieldsets. It sounds like you have your own solution that is working for you.

Your original image has an AdobeRGB colour profile. Because support for colour profiles is going to vary in PHP/GD/ImageMagick and from browser to browser it would be a good idea to convert and save your images with the sRGB profile which is the mostly widely supported. This was discussed recently on the forums here: More reading: https://fstoppers.com/pictures/adobergb-vs-srgb-3167

I was actually thinking of just manually removing the variations in Page Edit, but removeVariations() should also work (it works for me). What about using the forceNew option? Is that working for you?

I will certainly contribute any actions that would be useful to others, but I only have two so far (the ones you see in my screenshot) and one is a work in progress. The first just an interface for uploading a CSV file, but I don't think this is useful as an action to bundle with the module because the action doesn't do anything by itself - it requires code to process the CSV lines, which would depend entirely on what the user wanted to do. The second is part of an exploration of how to resize existing images to save on disk space. I have a lot of older sites from before client-side resizing was introduced, and users have uploaded massive images that waste a lot of disk space. I'd like to upgrade PW on these sites and then loop through all the oversized images and replace them with smaller versions. I've worked out how to do this, but again I don't think it makes for a useful action to share. Firstly, for a large list of images this should be broken into smaller jobs that run on a LazyCron (or maybe the new Tasker module) to avoid a timeout. And secondly this is a destructive process that has the potential to do a lot of harm if used incorrectly, so I wouldn't want to put this out there and maybe contribute to a disaster. Yes, that's what happened. No need to change from using the module config data to populate the table - I can understand why it wouldn't be good to parse all the files every time the list is loaded. But as a more general issue I think that perhaps module developers should rethink how values are populated to the module config page. Currently nearly all modules, mine included, set default/fallback values for config inputfields by just setting the value for the inputfield as it is added to getModuleConfigInputfields() (or one of the many equivalent methods for defining config inputfields). There is probably a tutorial somewhere that started this practice. The problem with doing this is that when viewing the module config page, there is no way for the user to distinguish between values that are actually saved to the config and values that will be saved to the config if the config form is submitted. I'm sure I'm not alone in expecting that when I view the module config page I am seeing the config values that do exist, not ones that will exist if I submit the form. Each time I think about this I get different ideas about what the best solution would be. Currently I'm thinking that we module developers should be saving the config values that we want to be the default config as part of the module install method. Then we don't set any default/fallback/other values in getModuleConfigInputfields() besides those coming from the saved module config. That way the user can have confidence that whatever they see in the module config page is data that actually exists in the saved config. And if the module does display config values that are not actually saved yet these should be highlighted in some way. Any thoughts on this?

Most likely the problem is that you already have an image variation at that size that was created with different quality, sharpening, gamma, etc. Settings like that do not form part of the variation file name so you receive the existing variation rather than a new variation being created. I made a wishlist item long ago requesting better handling of this. So you have to clear the image variations, or use the forceNew option in the $options array (just once, then remove it so you are not creating the new variation over and over again).