Leaderboard

Hey Mr MetaData! Yeah sure why not. Since it does add value and it's only optional I think this is good idea to add. I just went ahead and added support for MetaData in my last commit. You could now add a field "image_exif" and get the EXIF data stored when uploading images. I made the method setMetaData(), which adds the meta data on page/image creation, hookable so you can do a hook on it to store additional data. Not sure if this a good idea but maybe nice to have. v 0.0.3 fixed issue with images getting added twice to the assets folder (hope this is now ok) removed the performance intense pages search for image tags (In my testinstall with 120k pages this result in many second waiting to load the data table. and just output a link on all images to a PW search that will run a search. added EXIF data support. Let me know if that EXIF data reading is ok, or if it need a more sophisticated method. You can hook the Meta Data method like this from a autoload module: $this->addHookAfter("ImagesManager::setMetaData", $this, "hookMetaData"); public function hookMetaData(HookEvent $event){ $page = $event->arguments[0]; // page that the image will be added $file = $event->arguments[1]; // path of file in temp upload folder // do whatever you like $page->yourfield = "I'm the Meta Man!"; // will be saved to page }

Thanks Steve! That's very kind of you. What you may not know is that I've been raising my beer glass to all of you this whole time. Here's the rest of my profile photo

PW Images Manager (beta) Just a weird little screencast trying to show how it works. (out of date a little, tags now use a textfield for easy copy/paste) This module allows you to manage images from one central repository. You create a root page "/images/" where you can then add categories and images as pages. From there the new admin page created "ImagesManager" will show categories and images added in a ajax data table, from where you can see and search/filter all images, upload and create new categories and edit images too. Every image will also show an image tag generated to copy into a textarea. This tag looks like this: {image=/path/to/image/imagename/, width=200}The width=100 is the thumbnail size used to output the image.You can also have additional segment to contain classes: {image=/path/to/image/imagename/, width=100, class=align_left}Or you can enter the id directly: {image=1033, width=100}Once inserted into a textarea field it will get parsed when saved and loaded automaticly. It will store an abstract id tag in Database and convert it back to the image HTML tag. So after first save you'll see the image inserted in a Wysiwyg and be able to resize and place it as usual. Once it's inserted somewhere Images Manager will show a search link with the pages containing the image (you can configure the fields int the module setting). You can change the image or move it to a different category, it will still work and show the correct image. This also works with multi-language fields.You can still also use the regular insert image dialog in TinyMCE and chose image from those pages. And it will start keeping track of those as well (they're the same after all). You can use those central images pages also with page fields to reference them single or even whole categories, search them with API and do what you like. Images Manager will also parse the page render on front-end and replace any found image tags with the HTML code. It will also look for a description on the image and output it as alt tag. If you want to have multi-language description you can add a `image_description` TextLanguage field to the image page template and have images parser use them. Along with this module, you can also install the `PageListImageLabel` module to add thumbnails to the image pages in the tree. To get it working you need to have the basic setup: 1. Create new `image` field with input setting to 1 max image 2. Create new `image` template and add `title` and the `image` field created before 3. Create a 'image-category' template with only title and allow the `image` template and `image-category` as child pages under family settings. 4. Create a `image-root` template with only the title field for the root of the images tree. Allow only `image-category` as child page under family settings. 5. Create the root page with the `image-root` under the home page as "/images/" 6. Done. The structure of the image repository looks like this /images/ /cagetory1/ /imagesxy/ /category2/ /image2/ /image3/ Now you can use the ImagesManager to add categories and images. But you can also still use the page tree to add new stuff as usual. The root path, template names and fields are configurable in the module settings. How to install the module: - Download the contents of this repository and put the folder renamed as "ImagesManager" into your site/modules/ folder - Login in to ProcessWire and got to Modules page and click "Check for new modules". You should see a note that the two new module were found. Install the "ImagesManager" module. - A new admin page "ImagesManager" should appear in the top menu. - You may configure the option on the module screen to suit your needs. Download at github https://github.com/somatonic/ImagesManager Thanks and enjoy.

I think you should do this control in the templates. You can have a page for each drama, and children pages or a repeater for all the shows of that drama. On them you will have a date field with the time of the show. Then on the template you can do this: if (($page->date - time()) < (3 * 60 * 60)) { // 3 hours in unix time // tickets can't be sold anymore } and if (($page->date - time()) > (7 * 24 * 60 * 60)) { // one week in unix time // tickets are available from now on }

Hmm, wire("modules")->get("ImagesManger")->options[key] should be enough The module sets the options array in the init. But you can also get it when you hook setMetaData() with $event->object->options['imagesEXIFField'];

By emitting a newline escape sequence at the end of your echo statement: echo "<link rel='stylesheet' type='text/css' href='{$config->urls->templates}$file' />\n"; For the new line, same thing as above. For the alt text: <?php foreach($page->images as $image) { echo "<img src='$image->url' alt='$image->description'>\n"; } ?> Of course, the proper alt text will only be emitted if you or your editors actually enter an image description in the PW backend. Also, I would advise to emit the images as an unordered list here. That's what they are semantically. You can remove the list bullets using CSS, of course.

Hey Soma, very cool Manager! (it's not the first time I say this, but it can't be said to often ) I want to ask if it is possible and if you find it useful, to include an optional userdefined callback-function that gets invoked in the public function executeUpload() method at line 517. After successful upload and the new ImagePage is saved calling it for example like this: if( ! empty($this->options['userCallbackUpload']) && function_exists($this->options['userCallbackUpload']) ) { ${$this->options['userCallbackUpload']}( $imagepage ); } With this, users may have a simple way to extend imagesPageTemplate with some more fields (e.g. for Exif-data). Yes, actually they allready have this option to extend the template or provide an own, but it would only allow to do a manually populating of fields. With a userCallbackFunction it could be done automatically. Is this not of interest for the ImagesManager himself? You may read Exif-description and IPTC-description fields and populate automatically the ImageDescriptionField. (IPTC has higher priority as EXIF). So, if a user uses IPTC-description the field is allready filled, if not, and Exif-Description is available, this is used. Downside: If there is unwanted text populated, the user has to change it manually. But with nothing populated automatically the user allways has to do it all manually. Maybe it could be an boolean option: 'Yes, do autopopulate the image description' or 'NO' ? EDIT: approved code for reading this I can provide, - as you've said elsewhere: i'm the 'metadata-man'

Hi Marty, Hi MarcC, I'm not sure if I understand the question/s right, but I can point out some things that come to my mind when reading it: The imagesfieldtype currently has only one description field what can collect data. This is a Textfield and can store data up to max 64kB. Depending on what EXifdata you need, it maybe a possible approach to store that with the description field (serialized?). Accompanying resize-methods to the imagesfield needs to create an own imagesfield with this extensions. (Like ThumbnailsModule) But I would prefer to store each image as a page and have all wanted single exif-data on that template as fields. To use images as pages is often discussed here, because it's flexible and scalable. Also Somas ImagesManager could be of interest. So, regardless on how you organize your images, I think it would be pretty usefull if the fields get populated automatically somehow, - at upload for example. Saying that, I actually don't really know how to do it. (I'm PW-newbie (somehow), - hook into upload with a module - ok, but what comes after hooking may be very individual on someones need) --- Note: when applying any Imagemanipulation with GD, every EXIF-data get stripped and is lost! You should not manipulate your original images! --- For reading and sorting Exifdata (and IPTC-data) I can provide some code if wanted.

Very interesting tool from Mozilla, Just tested it on a site only by pasting a script,and works fine https://towtruck.mozillalabs.com/

That sounds fine, no problem if it takes some time. Maybe i could lend you a hand in implementing this?

We have it build in. Thanks Ryan.

Bravo! This'll open the flood gates to folk who expect this functionality in whatever CMS they use. "Somehow connect the image manager to a standard image field" <- An uber image field I rarely stick images into a wysiwyg editor and I have dreams where the standard image field can either accept an upload or link to another image on another page.

And I've been raising a fish.

That made my day! ROFL!

Evan, make sure you sanitize $_POST['email'] before putting it into the selector. Since you are dealing with a page name, I recommend this: $name = $sanitizer->pageName($input->post->email); $my_page = $pages->get("template=template-photo, name=$name, include=all"); "check_access=0" will cause it to include pages that the user doesn't have permission to view as a result of access control. It's what you'd want to use if you wanted to (for example) generate public listings for pages, but only full members could view the whole page. In that fashion, you could have the page appear in lists to everyone, even if only the members could view it. The non-members could get a login page when they click on it. "check_access=0" won't cause unpublished or hidden pages to be included. Whereas "include=all" will include everything regardless of access, publish or hidden state. Any function that returns a PageArray (like $pages->find or $page->children) will have this access checking enabled by default, unless you turn it off with include=all. But functions that return a single page (like $pages->get) don't check for access/status since they are returning a pre-determined (by you) item and quantity, and aren't likely to be used for making navigation.