Robin S

Can you give a more detailed report please? What are the image URLs you are trying to add when you see the error notice? Is the issue reproducible? i.e. if you try again with the same URLs do you see the same notice? If you download the images to your computer and then upload as per a normal addition to an images field, do they work then? Anything special about your images field - e.g. inside a Repeater or PageTable? The error seems to be related to the field name. Could you please post a screenshot of your browser dev tools showing the source code of the textarea input that this module adds to the images field (like the one below)? That will help me get to the bottom of this. Thanks.

Yeah, that is difficult. Instead of including a copy of InputfieldIcon, another approach could be to auto-install a custom inputfield module (e.g. InputfieldIconFaPro). Then hook into the form rendering of ProcessTemplate and ProcessField and remove the existing inputfield, adding InputfieldIconFaPro in it's place with the same name (so it still reads/writes the "icon" property). Here are the classes (got them with some regex find/replace in file web-fonts-with-css/scss/_icons.scss):

Ha, sorry. Not expecting delivery of the all-singing, all-dancing image reference module. What I meant is that due to needing to be kept in sync with the feature set of the core image inputfield/fieldtype, a full solution for an image reference fieldtype probably needs to come from Ryan, either as a core feature or a pro module. But I don't think we can expect that any time soon.

Looking good! Thanks for working on this. PW really needs an "image reference" fieldtype (wishlist topic). Several times I've thought about tackling it, but seems like a lot of work because users will be expecting a feature set matching the core images inputfield: sortable, scalable thumbs, different thumbnail views, etc. Not to mention new challenges like setting tags or description on the reference that is different from the source tags/description, how to handle deletion of the source image, etc. Quite tricky.

Ah, I should have known there would be something in PIA for this - it's the real Swiss Army Knife for images. I really need to have a proper explore of that module. (I think it's the state of the docs that has been putting me off - maybe you could consolidate/tidy everything into the GitHub readme?) I have a very primitive system. For modules I'm interested in I have a spreadsheet with name, category, link, brief description of what it does (in my own words). But I often forget to update it with new modules and just try to rely on memory. For forum snippets (and links to the original post) I just have a folder with a bunch of text files in it. The text files are named according to what the snippet is about. Then when I'm looking for something I use the quick filter feature in my file manager (XYplorer).

Actually, you can shorten the CSS override to this: .cke_panel_list * { font-family:sans-serif, Arial, Verdana, "Trebuchet MS"; font-weight:normal; font-style:normal; font-size:14px; }

And if it's mainly within CKEditor fields that you want to reuse images from a central media library then there is this module from @BitPoet: Media Library

In /site/modules/InputfieldCKEditor/contents.css: .cke_panel_list h1, .cke_panel_list h2, .cke_panel_list h3, .cke_panel_list h4, .cke_panel_list h5, .cke_panel_list h6, .cke_panel_list pre, .cke_panel_list address { font-family:sans-serif, Arial, Verdana, "Trebuchet MS"; font-weight:normal; font-style:normal; font-size:14px; } Do likewise for any custom styles you have added to the Styles dropdown.

Here's an alpha proof-of-concept module if anyone is interested in taking it further: https://github.com/Toutouwai/FieldtypeFileUnrenamed/

Okay, I got the vendor folders sorted - it's the ones in the "on-server" folder, right? I can see the basic v5 icons but I can't seem to view the new v5 Pro icons. Even with Selectize enabled for the icon select in SelectizeTemplateFieldTags I can't find the "alarm-clock" icons, for instance. A few other little things: 1. In FontAwesomePro.module, $this->config->urls->$name . "vendor/js/v4-shims{$min}.js?v=$version" should be "$this->config->urls->$name . "vendor/js/fa-v4-shims{$min}.js?v=$version" 2. In the readme/info for SelectizeTemplateFieldTags it could be clearer that the module has a dependency on the JquerySelectize module. The module gives a JS error that can stop the admin interface from loading properly if JquerySelectize is not installed. 3. It's a little hard to find the JquerySelectize module in the modules directory because it is listed under author "outflux3" instead of "macrura".

Thanks. Still not sure about adding the Font Awesome files though. Maybe you could spell it out a bit more in the readme? When it says "css, js, sprites and webfonts folders", which ones exactly? There aren't folders with those names in repo root - it looks like this... ...and there are multiple folders named "css" within the repo structure. Thanks.

@adrianromega, did you see the "Example use" section above? To expand on this... it's useful in any situation where you want to be fair to a group of images with different aspect ratios. Take the three images shown in the screenshot above. If these images had been resized using maxSize(800,800) for instance, photo 2 (the square image) would be larger than the others in total area - it would contain the most image data. Now suppose you're running a competition on your website where visitors can vote for the best photo. The three images above have been submitted by three different photographers. If you are resizing by maxSize() rather than megapixels then it's not fair on photographers 1 and 3 that their images are shown smaller than the image from photographer 2.

Hi @Macrura, Is this module working with the latest Font Awesome 5 Pro releases? The readme says to copy the Font Awesome files to the module directory and rename the outer folder as "vendor", and I see paths like below in the code: $this->config->urls->$name . "vendor/css/fontawesome-pro-core.css?v=$version" I have an early Release Candidate version of FA Pro 5 that has paths like that, but the recent versions look like this... ...and there is no file included anywhere named "fontawesome-pro-core.css". Another question: when the module is installed, does it replace the core icon preview with the icons from FA Pro 5?

One more option, but requires a pro module. Lister Pro has a delete/trash action in its set of bundled actions. I use this one a lot.

Inspired by the "max megapixels" option for the client-side image resizer, I made a simple module that adds target megapixel resizing for Pageimages. Image Megapixels A module for ProcessWire CMS/CMF. Adds methods to Pageimage objects useful for resizing to a target megapixel value. Example use You are creating a lightbox gallery of images with different aspect ratios. For the enlargements, rather than setting a fixed maximum width or height you want all the enlargements have the same size in terms of area, allowing a panoramic image to be wider than a square image, for instance. Another use case is sizing a gallery of sponsor logos. The supplied logos are different aspect ratios but you need to ensure the logos are sized so each has equal prominence on the page. The effect of resizing three different aspect ratios by the same megapixel target value can be seen in the screenshot below: Installation Install the Image Megapixels module. API // basic usage $pageimage = $pageimage->megapixels(float $megapixels); // usage with all arguments $pageimage = $pageimage->megapixels(float $megapixels, array $options = []); Example: foreach($page->images as $image) { echo "<img src='$image->megapixels(0.8)->url' alt='$image->description'>" } If needed you can supply an array of options for Pageimage::size() as a second argument. Getting dimensions If you just want to get the height and width dimensions needed to size an image to the given number of megapixels you can use the Pageimage::megapixelsDimensions() method that this module also adds. It returns an array with width and height as keys. Example of how this could be used to output a gallery of logos: foreach($page->logos as $logo) { $dimensions = $logo->megapixelsDimensions(0.01); $width = $dimensions['width']; $height = $dimensions['height']; $width2x = $width * 2; $height2x = $height * 2; echo "<img src='{$logo->size($width, $height)->url}' srcset='{$logo->size($width, $height)->url} 1x, {$logo->size($width2x, $height2x)->url} 2x' alt='Logo' width='$width' height='$height'>"; } https://github.com/Toutouwai/ImageMegapixels https://processwire.com/modules/image-megapixels/

The documentation could be clearer in this regard, and I'm probably oversimplifying here, but there two basic categories of selector usage in PW. 1. Methods that use the PageFinder class - common ones would be $pages->find($selector), $pages->get($selector), $page->children($selector). Also find/get selectors for $users. Those are the ones that spring to mind, although there might be a few more. These methods do a database query behind the scenes. 2. All other methods that accept a selector, for example $some_pagearray->find(), which is actually WireArray::find(). These methods do not query the database but work on items that are in memory. There are differences in the ways that these two categories of selector usage are implemented. Some things work in a PageFinder selector that don't work in an in-memory selector. The documentation for Selectors seems to be assuming the reader is interested in PageFinder selectors because there are code examples there that won't work with in-memory selectors. There isn't any definitive list of the differences (that I know of), but here are some things that I have found do not work with in-memory selectors (but do work with PageFinder selectors): 1. Datetime values as strings, e.g. "some_datetime_field>today" 2. Page statuses as strings, e.g. "status!=hidden" 3. OR groups In a perfect world selectors would work the same everywhere and you wouldn't have to think about it. There's an open request for this here.

I don't think OR groups are supported at all in WireArray (therefore PageArray) methods - adding support for OR groups inside a single PageArray selector is what BitPoet's module above is all about. But if you are doing what I suggested with find() and add() then you don't need the OR group parentheses. It's a different approach but should result in the same thing as OR groups inside a single selector.

In this example you only have a single query for modifying the original PageArray. So you don't need add() here - that is only needed for cases like your earlier example where you have multiple queries to apply to your PageArray where you want to say "find this" OR "find this". // Your original PageArray (which you will reduce down from) $pagearray = $pages->find($selector_1); // First modifying query $results = $pagearray->find($selector_2); // Stop here if you only have a single modifying query // Otherwise if you have additional OR queries, add them to the results $results->add($pagearray->find($selector_3))

See here for how you can add those settings via hooks:

Not necessary I think. As far as I know PageArrays are always unique (they never contain the same page more than once).

You could filter the PageArray more than once and add the results together. Actually, filter() is destructive so use find() instead. $results = $pagearray->find($selector_1)->add($pagearray->find($selector_2));

I remember you mentioning this in the FB subforum and it's a nifty solution. In terms of letting editors add the repeatable field, you could bundle the bits into a custom inputfield module and then include it in the types allowed for FormBuilder.

There's no performance issue with having any number of pages under a parent - the admin page list (and Lister) are ajax-driven and paginated for this very reason. I'm not aware of any module that creates virtual folders of pages in this way. Rightly or wrongly, ProcessPageList doesn't really lend itself to being manipulated like this. If you wanted to have the posts inside real year/month parents you could try the ProcessDateArchiver module. It's hasn't seen any updates in a while but maybe it doesn't need any (I haven't tried it). Or, if you're keen to get your hands dirty in code you could make a custom Process module with selects for month and year, and a datatable that lists matching blog posts. @bernhard has written a great tutorial for getting started with Process modules.

It's not that I think the PW admin isn't easy, but there are lots of scenarios where users don't need to edit site content in any big way and seeing the PW admin would confuse them more than anything. Like where your users just have an account so they can access a private "members" area, or view "premium" content, etc.

Via a custom front-end login form. I think that's how most of us have been dealing with front-end logins (until the LoginRegister module came along - I haven't had the chance to use it yet). Well, it's not unusual. Guess it depends how many sites you build that service front-end users.