Leaderboard

Hello all, sharing my new module FieldtypeImageReference. It provides a configurable input field for choosing any type of image from selectable sources. Sources can be: a predefined folder in site/templates/ and/or a page (and optionally its children) and/or the page being edited and/or any page on the site CAUTION: this module is under development and not quite yet in a production-ready state. So please test it carefully. UPDATE: the new version v2.0.0 introduces a breaking change due to renaming the module. If you have an older version already installed, you need to uninstall it and install the latest master version. Module and full description can be found on github https://github.com/gebeer/FieldtypeImageReference Install from URL: https://github.com/gebeer/FieldtypeImageReference/archive/master.zip Read on for features and use cases. Features Images can be loaded from a folder inside site/templates/ or site/assets Images in that folder can be uploaded and deleted from within the inputfield Images can be loaded from other pages defined in the field settings Images can be organized into categories. Child pages of the main 'image source page' serve as categories mages can be loaded from any page on the site From the API side, images can be manipulated like native ProcessWire images (resizing, cropping etc.), even the images from a folder Image thumbnails are loaded into inputfield by ajax on demand Source images on other pages can be edited from within this field. Markup of SVG images can be rendered inline with `echo $image->svgcontent` Image names are fully searchable through the API $pages->find('fieldname.filename=xyz.png'); $pages->find('fieldname.filename%=xy.png'); 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 with links to help you edit those pages and remove references there before you can finally delete the image. This field type can be used with marcrura's Settings Factory module to store images on settings pages, which was not possible with other image field types When to use ? If you want to 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 (e.g. icons, but not limited to that). Other than the native ProcessWire images field, the images here are not stored per page. Only references to images that live on other pages or inside a folder 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) Installation and setup instructions can be found on github. Here's how the input field looks like in the page editor: If you like to give it a try, I'm happy to hear your comments or suggestions for improvement. Install from URL: https://github.com/gebeer/FieldtypeImageReference/archive/master.zip Eventually this will go in the module directory, too. But it needs some more testing before I submit it. So I'd really appreciate your assistance. Thanks to all who contributed their feedback and suggestions which made this module what it is now.

There is already a feature similar to this - it's the "Name format for children" setting on the template of the parent page. https://processwire.com/docs/modules/guides/process-template/ ID is not one of the supported options, but if you want the page to be named with the ID you can install @kixe's module which extends the functionality of this feature. http://modules.processwire.com/modules/process-setup-page-name/ Or you can enter something like a date format ("Y/m/d H:i:s") in the core "Name format for children" setting, which allows you to skip the Page Add step. And then set the page name and title to the ID with a hook in /site/ready.php: $pages->addHookAfter('added', function(HookEvent $event) { $page = $event->arguments(0); if($page->template == 'your_child_page_template') { $page->setAndSave([ 'name' => $page->id, 'title' => $page->id, ]); } });

Did you check your browser JS console as well? Keep an eye on the network tab as well (you can filter by XHR).

Did you try custom (field / value) and then "modified>=today" ? (modified=today for some reason doesn't work) (manually entering modified>2018-01-01 14:00 worked for me too)

I use a modified excerpt from @Robin S's module to add an image from a url like so: $field_value = $p->getUnformatted( $yourField->name ); if ( $yourField->maxFiles == 1 && count( $field_value ) ) $field_value->removeAll(); $pageimage = new Pageimage( $field_value, $url ); $field_value->add( $pageimage );

Hello group, I would like some input on how to store the data for a project I'm currently working on. It is a Backoffice application for teams, where each day is divided into 4 sections, representing the eight working hours in a day as two-hour time slots. The time slots will be filled with a letter and a color, indicating the task that the team member is appointed to at that time. I have attached some screenshots so you can get a general idea of what it looks like (tried to make a GIF screencast with 'peek' but the file turns out too big every time to post here). The attached files show the Backoffice application itself and how I organized it in the back end of Processwire. Teams are pages, containing functions in the team. The members of a team are implemented as an ASM select field on the functions pages, that point to the Admin->Access->Users pages. Every user has access to their own profile page in the back end, but no other pages are allowed for them. As for storing the time slot data. I could create a separate database, or use Processwire to create trees of pages --under the Users pages-- with the date timestamp and task ID for that day, but I don't know yet how that would scale in Processwire when there is more-and-more page data in the Backoffice over time. With many team members, that tree could grow quite large, because it has to also be kept there as an archive for making reports about the working time the teams and members spent on what tasks in the past. So, I would appreciate some input from you on how you would store the time slot data in a case like this. Kind regards, Elko PS: I've been using Processwire since March this year and really like it so far, so thank you for making a great product like this.

No restrictions on the address (I've experimented a lot with the module restrictions) and I have it whitelisted in the SPAM filter. It's weird that from that same address, some emails work fine and some don't. I would expect that it would be all or nothing. At any rate, I may work on switching the module over from the Flourish library to the newer/better/maintained Fetch library. Another approach I'm toying with is to just have the email address pipe to a script on the server that bootstraps PW's index.php and simply creates the page. No need to mess around with checking an email account, etc.

@rick Thanks for that - I'll give it a try. I'm beginning to think that either I'm remembering how to interact with image fields incorrectly or my 'photo' field, which is set to contain 1 image ('photo' not 'photos') somehow isn't respecting that setting. And therefore that the error is unconnected to the new image field template setup.

See the docs to understand the difference between $pages->get() and $pages->find(): https://processwire.com/api/ref/pages/get/ https://processwire.com/api/ref/pages/find/ You want $pages->find(). And you only want to execute it once and use $results for both the results list and the pagination. $results = $pages->find("template=product, limit=10"); // Results list foreach($results as $result) { // Output each individual result // ... } // Pagination echo $results->renderPager(array( 'nextItemLabel' => 'Volgende', 'previousItemLabel' => 'Vorige', 'currentItemClass' => 'active' ));

@Kiwi Chris, I think you want to make use of Inputfield::hasPage in this case. $wire->addHookAfter('InputfieldPage::getSelectablePages', function(HookEvent $event) { /* @var InputfieldPage $inputfield */ $inputfield = $event->object; $field = $inputfield->hasField; $edited_page = $event->arguments('page'); $page_containing_inputfield = $inputfield->hasPage; // a Repeater page in your case if($field->name === 'pageBatch') { // Use $page_containing_inputfield as needed here // ... } });

Found this article to be a good read: https://tsh.io/blog/tips-on-keeping-php-code-under-control/

Welcome @Elko! From comments that I've seen here in the forums I know that there are people using PW successfully with millions of pages. So that might mean that there is nothing to worry about if you decide to use a page for every time slot for every user. But personally speaking, when I've had situations like this it has felt a bit wrong to use large numbers of pages to store such simple data and I have used Profields Table for this sort of thing instead. This isn't based on any tests I've done - just on gut instinct. I have a feeling that if you need to regularly and quickly load and process large numbers of records then pages can be a bit less than optimal. @bernhard's RockFinder module might be useful to avoid loading full Page objects: Or if you're comfortable working with databases then there's no reason why you couldn't use an external database (or just an extra table in the PW database) together with the $database API. This might give the fastest performance.

I had this problem once and solved it with JSON. It is quick and simple. In your case $logmsg = array( 'Email' => $emailvalue, 'Betreff' => $subjectvalue, 'Nachricht' => $commentsvalue ); $log->save('contact-form', json_encode($logmsg));

I've done quite a number of forms with this type of setup, not sure if any of this js would help but just in case... (using custom timepicker init and callbacks)

Also if used only from company network, you could use IP restriction: http://modules.processwire.com/modules/page-render-iprestriction/