gebeer

Thanks for that link. I first was taking a similar approach, passing a fake page to construct the Pageimages object. But every time I added an image from the folder to the Pageimages instance with $pageimages->add($pathtofile) it would add this file to the folder again. So with every add() call I created redundant extra files. BUT I didn't pass a Field instance like you did. So will give this a try.

At the moment these are strict requirements. To be honest, I wasn't aware of the fact that JSON data type in MySQL requires InnoDB. The module, as it is now, will not work on MySQL < 5.7.8 I added that info to the module requirements. Almost all of the sites that I am working on run on MySQL >= 5.7.8. InnoDB. But I understand that not every site can fulfill these requirements. After reading your comments here about this possibly being an issue for some people, I am thinking about redesigning the storage part. ATM I already have separate columns for storing pageid and filename plus that extra JSON column. Will contemplate some more and see if I can come up with a good solution. Maybe only using json if the hosting environment supports this. I'll see.

Now that the major update for my ImagePicker module is out, I wanted to share how I managed to make images from a folder in site/templates/ behave like a Pageimage with full resizing/cropping capabilities. This was probably the biggest challenge in developing the new features. I first thought to create a hidden page in the page tree that will hold all these images. But this would not have been a clean solution. So I took a closer look on how the Pageimage and Pageimages objects are constructed. Finally I decided to use a virtual (or fake) page to hold the images. It required some method overriding of the Page class and the PagefilesManager class to adjust the paths. Normally images for a page can only live in a folder in site/assets/files/pageid. By manipulating the path of Pagefilesmanager I was able to create a custom ImagePickerVirtualpage object and assign the images from the folder to that page. The virtual page is created at runtime and the DB never sees it. It took quite some trial and error to accomplish this. But finally, you can now manipulate these images just like any other Pageimage object (resizing/cropping). The resulting image variations will be stored in the same folder. There is one little stumbling block. I use an existing images field from the site my field is installed on and assign it to a virtual template of my virtual page. This field then holds all the folder images. I figured that every site that will use my module will already have an images field installed. Very rarely this will not be the case. So for the time being I am leaving the logic as it is. If I find people running into problems, I will adjust this. Code can be found here. One more thing that offered some challenge was storing the data as JSON in the DB and have it fully searchable through the API. Luckily I found an old (and abandoned?) module JsonNativeField from @BitPoet that does just that: store values as JSON and make them searchable. So I borrowed the DB schema and most of the getMatchQuery logic from that module. I still have 2 extra columns for pageid and filename in the DB table. These make sure that in the Pagefinder you can use subfields. Kind of redundant info in these columns but I couldn't figure out another way of making the subfield search work in Pagefinder. If you happen to know how to accomplish this, please enlighten me. Main advantage of JSON storage is that my image field can be used with the marcrura's SettingsFactory module. Also storing values of multiple images this way will be easy and will come in handy once I extend my module to support multiple images.

Yes, they do. You can pass a lang parameter to your query to get results in a specific language. Just tested this with Russian http://api.geonames.org/countryInfoJSON?formatted=true&lang=ru&username=gebeer&style=full Information on the webservices they offer: http://www.geonames.org/export/web-services.html Documentation is a bit sparse...

Seems it is still maintained and pretty up to date: https://www.geonames.org/recent-changes.html

It is done. I have merged this module with the ImagePicker module. Now it includes almost all requested features. It is published as FieldtypeImagepicker on github. I will update the ImagePicker thread shortly and continue discussion there. Hope to see you!

Thing about country info is that it changes all the time. I find https://www.geonames.org/export/ws-overview.html a good resource for getting up-to-date country information. They have a JSON and an XML API. And the country info also available as CSV. You can query for all countries JSON with http://api.geonames.org/countryInfoJSON?formatted=true&username=gebeer&style=full (note my username. You'd have to create your own) I used this on a custom address field type that pulls in location data in real time while filling in an address https://github.com/gebeer/FieldtypeAddressGeonames Developed it for a course directory site where 1000+ users login from all over the world, to make sure the address info is as uniform as possible.

I think you need to return the modified argument $forms->addHook('FormBuilderProcessor::renderReady', function($e) { $form = $e->arguments(0); if($form->name != 'enquiry_form') return; $inputfield = $form->getChildByName('cart'); if($inputfield) { $cart = json_encode(wire('session')->get('cart')); $inputfield->attr('value', $cart); // you can try var_dump($inputfield->attr('value') here to see if the value was set } $e->arguments(0, $form); // this will return the modified form object to the hooked method });

Please provide some more information: - ProcessWire version - which site profile did you use on installation? - where did you try to add a new page in the page tree (Home or other page)? - which templates did you create apart from home and basic-page? - did you change the 'Family' settings of any of the templates? It is hard for us to guess all these things. This information will help us to help you.

Thank you for testing! This is intended behaviour at the moment. But I am planning on incorporating an upload widget for the folder images, too. For uploading the page images the module uses the standard PW page edit feature. But since folder images are not linked to a page (at least not yet in the current version), I need to use a different solution here. I like https://uppy.io/ a lot and think I will implement it for managing images in the folder. I have merged all the features of this module into my ImagePicker module and will release a new version of that this week.

This is basic PHP looping over an array. Since $blogimages is an array, you need to foreach over it to output every image in that array <?php $blogposts = $pages->find("template=blog-post"); foreach($blogposts as $blogpost){ $blogimages = $blogpost->images; foreach($blogimages as $image){ $imgthumb = $image->size(500, 300); echo "<img src='{$imgthumb->url}' alt='{$imgthumb->description}'>"; } echo "<h2><a href='{$blogpost->url}' >{$blogpost->title}</a></h2>"; echo "<p>{$blogpost->body}</p>"; echo "<br>"; } ?>

Glad you sorted it! This is on purpose. Otherwise the filename would overflow the background area, especially on not so wide previews. Doesn't look very nice as it is, I know. In the CSS I had hyphens: auto; before but that would break the filename to the next line too soon. So I decided to go for word-wrap: break-word; instead.

Really sorry for the trouble. Maybe caching issue? The 2 modules were never supposed to be installed alongside each other and I didn't take that into account since it is planned to replace the 'old' ImagePicker module with this one. Added a warning to my post above so others won't fall into that pit.

Sorry for that one. InputfieldImagePicker did not manipulate any other image fields. Was your field 'image' created from InputfieldImagePicker? If so, you need to remove it and the error should be gone

regarding that error. Do you also have my module ImagePicker installed on that site?

Thanks for reporting. I was thinking about that one, too. But then I decided to allow only one images field because it might confuse users. But then, if I allowed multiple fields, the user could upload to any images field and have them available for the picker. Think, finally I will add this.

I have made good progress and have a working version now, that allows to pick an image from a predefined page (and optionally its children), a folder inside site/templates or the page that is being edited. The version is available in the branch 'allinone' on github. Install from URL https://github.com/gebeer/FieldtypeImageFromPage/archive/allinone.zip If you find the time, please do some testing and report your findings. Thank you. If you test, please uninstall previous versions and install this one. EDIT: Also uninstall InputfieldImagePicker if you happened to install it. My code does not cater fully for DB update, yet. And since I switched field value storage to json, atm this has to be installed from scratch. The module is still on that repository. But eventually I will publish it on the ImagePicker repository when I feel it is ready. One thing I still have to solve: ATM the field returns 2 different objects for rendering in templates, depending on where the image comes from. If it comes from a page, you will get a Pageimage object. If it comes from a folder inside site/templates, you will get a custom ImagePickerFile object. The latter one cannot be manipulated (resizing/cropping) like a Pageimage but has some similar properties. I still have to find a way how to turn images from a folder that is not connected to a page into Pagimage objects. This is quite tricky. I wonder if anyone who is reading this has evr tried to accomplish something similar. I really always want to provide a Pageimage object, no matter where the real image file lives so that it can be manipulated. Still scratching my head on that but hope I will find a solution.

You can have a look at my relatively new help videos module. Relevant code starts here. All the basics for creating fields and templates and pages are there. Should be easy to build upon. The uninstalling part goes in the ___uninstall() method. You basically need to keep track about what you installed (e.g. save this info to your module config data) and then remove that stuff.

If you want to test it, you will have to use the branch jsonvalue from github.

@adrian @eydun Made some progress and have a working version that is compatible with @Macrura's Settings Factory module. I switched to handling my field value as json. Haven't published the version yet as I'm planning on incorporating it into the yet to be developed new ImagePicker module. If you want to have a peek, I can publish it to a separate branch on github. Just let me know. First I was in doubt about using json for the field runtime value and for storage. But now I'm confident that this is the way I will go with the new ImagePicker module. So that one will be compatible with Settings Factory. The next days I will be working on combining this module and my ImagePicker (pick from folder) into one with the additional feature of letting the user choose an image from the page this field liveson. The resulting module will be released under the name ImagePicker. Hope I can get it out before Xmas.

After giving it some more thought, I decided to merge the 2 modules and call the resulting ImagePicker. One thing I'm not sure yet how to best approach it: 1. should the options for choosing images from pages/folder/current page be exclusive, so that only 1 option can be set per field? Or 2. should it be possible to choose all 3 I guess, 2 makes more sense. The challenge will be to make the UI/UX of the inputfield lean, clear and easy to deal with. Instead of having the thumbnails underneath the preview image, I think with that many possible sources for images, it will be better to present them in a modal window.

Makes sense. Only concern I have is that the field configuration options will grow to an extent which might overwhelm the user. This is why I had decided to make this a standalone fieldtype and leave the ImagePicker for picking from folders. I will contemplate some more and maybe combine the two.

The use case you are describing does come up quite often. But I think this is going beyond the scope of this module. It advertises that you can pick images from predefined pages. And I don't really want to break out from that logic atm. But I'll put it on the wish list and see if I will add it as feature in a later version.

I'm an idiot ?

Thank you very much for taking your time and putting this visual together! I don't really want to have icons next to the preview image because in future I might support selection of multiple images. Larger icon near the thumbnails might be a good solution. Also please understand, that I do not want to make this a hybrid between native image fieldtype and my fieldtype. The fieldtype now advertises that you can pick an image from another page. If it would also allow to upload to the page it lives on, it might become confusing to the user. If you want to stay consistent with the UI, it has ? To me it looks odd having icons from different libraries on one page or even across pages. As long as there is an icon available for the framework I am using, I always prefer that one over an alien one.