gebeer

Updated to v0.0.5 on github New features: optional Ajax loading of thumbnails. Especially useful when field is used inside repeaters or has many images. edit link right next to the thumbnails for the page that supplies the images. When clicked, the images field that holds the images will be loaded in a modal window. After making changes to the images and saving, the thumbnails are dynamically reloaded Side note: while working on these, I discovered that you cannot assign custom attributes to InputfieldMarkup and InputfieldWrapper (both inherit from Inputfield class) with $field->attr('data-sth', 'value'). $field->setAttribute() also doesn't work. Anyone else also experienced this? Is it deliberate or a bug?

Thanks for testing. I have this behavior in my other module that allows to pick images from a single folder. But now that there is an option to also choose images from child pages, it would make the inputfield grow too high. Also if there are many images. I will implement ajax loading for the thumbnails on open and think that is better, especially for cases with many images or child pages or when the field is used inside repeaters. Good idea! Will add this. Maybe open in modal window and refresh thumbnails on close. Will be easy to implement once the ajax thumbnail loading is there. Thanks for the link. That would be one option but only works for installs which are up to date on the PW version. Repeater fields also open automatically if they have an error attached to them. That is another option. But implementation is quite complex. Still experimenting with this feature.

Will do that. Also think it is better. Only have to find a way how to open the respective repeater field on that page and ideally scroll to it. There should be a built in way to do this. I remember having read sth about it but can't recall where it was.

@adrian Yes, pretty useful ? I tested this in repeater matrix context and it works, even the deletion prevention. Only thing which is not so nice: when you have this field inside a repeater, the edit links to the pages that contain the image references are pointing to the repeater pages, not to the pages containing the repeater field. Do you think this could boggle editors? They normally never see the repeater pages in the system.

New version v0.0.4 released https://github.com/gebeer/FieldtypeImageFromPage Is now fixed Implemented this. Also think it is better to prevent deletion of images as long as they still are referenced from other pages. In this case now a detailed error message is displayed which contains a list of pages that have references to the image, with edit links for those pages. Following the edit links (they open in new tab) shows only the relevant field to be edited on that page. Not sure this works in repeater contexts, though. Will have to test. Sorry for that, it was late last night. It is now fixed.

Use the v0.0.3 version

That error is fixed on the latest release. To install it, download a new module zip from github and replace all the files inside the module folder with files from the zip.

No need to wait any longer ? Option for including child pages is added and live on github in the new master v0.0.2 . EDIT: It's the v0.0.3, getting late here

Thanks for spotting this. Will be fixed for the next release soon. This is not planned, as of yet, sorry. But if more people like to have that feature, I will eventually add it.

You can install this module from URL. Have a read here how to do this. In the 'Add Module from URL section' of the Module install page, paste this URL that points to the zip download from my github repo: https://github.com/gebeer/FieldtypeImageFromPage/archive/master.zip No need for the module name.

@szabesz ATM there is no option to choose whether child pages of the "image holder page" (home in your case) should be included or not. This would be a necessary option in your use case. Otherwise the inputfield would list all children of home as sources for images. Couldn't you just use another page as source for the images and than create the 2 fields "header image normal" and "header image tall" as fields with my fieldtype and assign them to all top level pages' templates? Anyways, sounds like an option to exclude child pages would be good. Think, I'm going to add this to the next release.

You can use a hook to ProcessPageEdit::execute to redirect users with those roles to the frontend page. Make a new file /site/ready.php and put this code inside: wire()->addHookBefore('ProcessPageEdit::execute', function (Hookevent $event) { $restrictedRoles = array('admin', 'frontendeditor'); // list your roles here foreach ($this->user->roles as $role) { if ($role->name !== 'guest' && in_array($role->name, $restrictedRoles)) { $this->session->redirect($this->config->urls->root); } } }); This will redirect users with given roles to the homepage of your site. Note that this will restrict them only from accessing page edit screen in the admin panel. If you like to restrict access to the whole admin area for those roles, you would need to hook into Page::render or Page::viewable and than check if the Page has template admin.

Hi @shogun and welcome to the forum You can also try echo page()->featured_image->render(); This should output a standard img tag. Read all about handling images in ProcessWire. And the API documentation is always a great place to look up stuff.

@adrian @szabesz and everyone who followed this discussion. I opened a new thread for the Module FieldtypeImageFromPage which is the new module that evolves out of this one after the discussion. Had a happy weekend of module coding ?. Please try the new module and let me know what you think. Cheers.

EDIT: all development and discussion of this module has been moved to Module FieldtypeImagePicker which now contains all features of this module and more. This module will not be maintained any further. The information below remains for pure historical reasons. I am happy to present my new fieldtype FieldtypeImageFromPage. It is made up of 2 modules: Fieldtype Image Reference From Another Page is a Fieldtype that stores a reference to a single image from another page. The image can be selected with the associated Inputfield. Inputfield Select Image From Page is an Inputfield to select a single image from images on a predefined page and it's children. And there also is a helper module that takes care of cleanup tasks. This module evolved out of a discussion about my other Module FieldtypeImagePicker. It caters for use cases where a set of images is being reused multiple times across a site. With this fieldtype these images can be administered through a chosen page. All images uploaded to that page will be available in the inputfield. When to use ? Let editors choose an image from a set of images that is being used site-wide. Ideal for images that are being re-used across the site. Suited for images that are used on multiple pages throughout the site (e.g. icons). Other than the native ProcessWire images field, the images here are not stored per page. Only references to images on another page are stored. This has several advantages: one central place to organize images when images change, you only have to update them in one place. All references will be updated, too. (Provided the name of the image that has changed stays the same) Features Images can be manipulated like native ProcessWire images (resizing, cropping etc.) Image names are fully searchable through the API Accidental image deletion is prevented. When you want to delete an image from one of the pages that hold your site-wide images, the module searches all pages that use that image. If any page contains a reference to the image you are trying to delete, deletion will be prevented. You will get an error message to help you edit those pages and remove references there before you can finally delete the image. How to install and setup Download and install this module like any other modules in ProcessWire Create a page in the page tree that will hold your images. This page's template must have an images field Upload some images to the page you created in step 2 Create a new field. As type choose 'Image Reference From Another Page'. Save the field. In 'Details' Tab of the field choose the page you created in step 2 Click Save button Choose the images field name for the field that holds your images (on page template from step 2) Click Save button again Choose whether you want to include child pages of page from step 2 to supply images Add the field to any template You are now ready to use the field View of the inputfield on the page edit screen: View of the field settings The module can be installed from this github repo. Some more info in the README there, too. In my tests it was fairly stable. After receiving your valued feedback, I will eventually add it to the modules directory. My ideas for further improvement: - add ajax loading of thumbnails Happy to hear your feedback!

This is what I'm trying to accomplish. Also I want to add a new property to Pageimage that holds the svg markup for inlining. Even if I add my hook inside the formatValue() method, it is not executed. Still fiddling. Will find a solution, eventually...

Yes, I am using Pages and Pageimages to retrieve and list them. Everything is working fine so far. Doing some more fine tuning. Have to cater for cases where an image got deleted from the page that holds all images but is still referenced from my Fieldtype on a page. And things like that... Can I make a fieldtype module autoload so that I can attach hooks to Pageimage and Pageimages from init() within my fieldtype? I tried, but it doesn't work.

@adrian @szabesz I am already working on implementing with child pages.

can do ?

@adrian I'm with you here. After contemplating some more, I think the page approach should be the only option, discarding the folder option in site/templates/. Since PW is all about pages, this makes more sense. Also editors can easily add/remove images as they see fit without having to use other tools like FTP clients. This also provides the manipulation methods from Pageimage class to all images. What do you all think?

@adrian While I think that this is a good idea, I am not sure yet, if I want to go that far with this module. This would add additional complexity when installing and I wanted to keep it as simple as possible. This addition would make it kind of a "mini media manager" and I don't know how high the demand for it really would be since we have kongondo's excellent media manager already. But if more people would like to have that option, I can implement it. Please vote.

Exactly the same thought came to my mind. Will implement this as an option.

@szabesz Actually I was thinking about making this change, too ? @adrian Great job! Could you make a PR with your changes? I'd like to implement them. This will also make the images instances of Pageimage and we get all image manipulation methods.

Have you tried httpUrl without the () ? In API docs it states that httpUrl is a property, not a function https://processwire.com/api/ref/pageimage/

I fork long running processes to the background. You don't need PCNTL functions for this. In an import module which takes some minutes to run, I have a file "importworker.php" <?php namespace ProcessWire; include(__DIR__ . "/../../../index.php"); // bootstrapping PW error_reporting(2); // setting error reporting // ini_set('max_execution_time', 300); // 300 seconds = 5 minutes wire('log')->save('productimport', "starting import: " . date('Y-m-d H:i:s')); $importModule = wire('modules')->get("ProcessImportProducts"); $importModule->importController('start'); wire('log')->save('productimport', "Import finished: " . date('Y-m-d H:i:s')); Then there is a method for forking the heavy work into the background public function startImportWorker() { $path = $this->config->paths->siteModules . "{$this->className}/"; $command = "php {$path}importworker.php"; $outputFile = "{$path}output.txt"; $pid = shell_exec(sprintf("%s > $outputFile 2>&1 & echo $!", $command)); return; } All output of the importworker script is piped to output.txt. So I can see what happens when the process is running in the background. Some methods in my module echo stuff so I can see it in output.txt. Also for longer running loops in my module, I use the ini_set('max_execution_time', 300) method to prolong execution time. And I unset variables along the way to take care of memory issues. With some ajaxy JS, I get the contents of output.txt and show them inside a div#status in my module, so the user knows that there is sth going on. var ProcessImportProducts = { init: function() { $('#startimport').on('click', function(e){ e.preventDefault(); $.get($(this).data('href'), function( data ) { // console.log(data); ProcessImportProducts.pollResults(0); }); }); }, pollResults: function(timestamp) { var statusUrl = '?getstatus=1'; var statusText = $('#status'); // var loader = $('.loader').clone(); if(!timestamp) statusText.html(''); $.ajax( { type: 'GET', dataType: 'json', url: statusUrl, success: function(data){ // console.log(data); // if file has changed append data to statusText if(timestamp != data.timestamp ) statusText.html(data.message).append('<div class="loader"></div>'); // call the function again, this time with the timestamp we just got from server var timeout = setTimeout(function() { ProcessImportProducts.pollResults(data.timestamp); }, 1000); if(data.timestamp == 0) { clearTimeout(timeout); $('.loader').addClass('hide'); } // scroll to bottom of status div statusText.scrollTop(statusText.prop("scrollHeight")); } } ); } }; $(document).ready(function() { ProcessImportProducts.init(); }); EDIT: heres the part of my ___execute() function, that returns the status stuff for the JS if($this->config->ajax) { if($this->input->start == 1){ $this->startImportWorker(); echo 1; return; } if($this->input->getstatus == 1) $this->returnStatus(); } else { // module output to screen } Here's a good read about running processes in the background: https://medium.com/async-php/multi-process-php-94a4e5a4be05 Hope that helps.