Robin S

A proof-of-concept module. ImageToMarkdown Alt+click an image in Page Edit to copy an image markdown string to clipboard. Usage Install the ImageToMarkdown module. Alt+click an image in Page Edit to copy an image markdown string to clipboard. If the "Description" field is populated it is used as the alt text. https://github.com/Toutouwai/ImageToMarkdown

I agree that you'd be better off with ordinary child pages than PageTable pages if there will be hundreds of them. Remember that you can access a paginated list of child pages from within Page Edit by visiting the Children tab, that you can long-click the "Edit" link to edit the child page in a modal, and that you can add extra fields to appear in the page list besides the title (and that can be further enhanced with AdminOnSteroids). So nearly as good a PageTable field.

Somehow I missed the enhanced icon select part of the module - damn, wish I found that earlier. I take you mean to propose changes for that in the core, because it isn't possible to do in a module.

@gebeer, I don't want to be pouring cold water on this but I have a feeling this approach is unlikely to work. At least not without giving the role edit access to the 'user' template, and it seems like that would be a security liability. But if you do get this working then cool. I suggest opening a GitHub request/issue to add proper support for FieldsetTab to ProcessProfile. Whether it's a request or an issue depends maybe on whether you think support for FieldsetTab was deliberately left out of ProcessProfile or was just an oversight. If you ask the responders in the other thread to "thumbs up" the issue on GitHub then hopefully Ryan will give it some attention soon. Until there is proper support in ProcessProfile you could consider if an accordion-style interface could be an okay substitute for a tabbed interface. You could change to closed Fieldsets instead of FieldsetTabs and then add a little JS so that only one Fieldset is open at a time (to keep the profile edit page from being overwhelming): $wire->addHookAfter('ProcessProfile::execute', function($event) { $out = $event->return; $js = " $(function() { $('.InputfieldFieldsetOpen label').click(function() { if($(this).parent().hasClass('InputfieldStateCollapsed')) { $('.InputfieldFieldsetOpen:not(.InputfieldStateCollapsed)').children('label').find('.toggle-icon').trigger('click'); } }); }); "; $out .= "<script>$js</script>"; $event->return = $out; }); You could stick with FieldsetTabs and adjust the JS to suit, but the open/close of the FieldsetTabs in ProcessProfile seems a little buggy to me (flickering, toggle icons in wrong state - not from the JS addition above, but untouched too).

But the idea is to filter the icons preview, not the select options.

Note: this functionality is now built into AdminOnSteroids. I'd hate to know how much accumulated time I have spent and how much eye-strain I have experienced over the last couple of years, hunting through the 675 icons in the "all icons" view for the one I want. Today I finally got around to doing something about it. IconsFilter Allows the "all icons" view in InputfieldIcon to be filtered by name. Usage Install the IconsFilter module. When viewing "all icons" in InputfieldIcon (Advanced tab of field/template settings) you can filter the icons by name using the filter input at top right. https://github.com/Toutouwai/IconsFilter @tpr, something that could be merged into AdminOnSteroids?

I'm not sure about this error, but just a correction to the code that is triggering it - line 204 in PW 2.8.35 is: $inputfield = $field->getInputfield($this->page); The legacy branch has been updated to 2.8.62 (despite what is says on the "Download" page) and the code in InputfieldRepeater.module has changed in this version. So you could try updating to 2.8.62 and see if that resolves the issue.

Yep, all went smoothly with an update from v1.0.0 beta - nice one

Yes, it was just a test of a first install. But just now I forked the module and added the new CroppableImage3.module to the module root (nothing else). With the current CI3 version already installed I installed the modified module via "Add Module From URL": https://github.com/Toutouwai/CroppableImage3/archive/master.zip This seemed to work without a hitch. Installing via the Upgrades module is perhaps a little different, but I have no way to test that.

Taking the current version of CI3 and adding this 'CroppableImage3.module' file in the module root enabled all the dependent modules to be installed/uninstalled in one go without any major problem for me: <?php namespace ProcessWire; class CroppableImage3 extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Croppable Image 3', 'summary' => 'One or more image uploads (optional predefined crops)', 'author' => 'Horst Nogajski', 'version' => '1.1.5', 'requires' => 'ProcessWire>=3.0.20, PHP>=5.3.8', 'installs' => 'FieldtypeCroppableImage3, InputfieldCroppableImage3, ProcessCroppableImage3', 'icon' => 'crop' ); } public function ___uninstall() { // Remove related modules on uninstall - not essential $this->modules->uninstall('FieldtypeCroppableImage3'); $this->modules->uninstall('InputfieldCroppableImage3'); $this->modules->uninstall('ProcessCroppableImage3'); } } Tracy picks up a few minor PHP notices coming from ProcessCroppableImage3 during install/uninstall but should be simple enough to iron those out. Lines 344 & 349 on install, lines 48 & 49 on uninstall - I think these notices occur with the current version too. If you went this way you could consider moving FieldtypeCroppableImage3.module back into a subfolder just to keep things tidy. Also, after adding this file the Upgrades module detects CroppableImage3.

Hi @Martijn Geerts, just a heads up that the current version number of this module is 0.0.1 - is that supposed to be 1.0.0? Because I've just noticed that the version I have been running is 0.8.7 which is older than the current version yet I never get an upgrade prompt in the Upgrades module due to the low current version number. Also, did you change GitHub repos at some point? There seems to be only a few months of commit history yet the module has been around much longer than that.

@horst, what if you create a new module file/class in the root of the CroppableImage3 directory named 'CroppableImage3', and that class does nothing apart from auto-install the other classes? Not ideal of course but might be an okay workaround seeing as you are stuck with the existing directory name.

Yes, I have my timezone set correctly in config. Not sure what caused that issue but after removing the Recurme field from the template, adding it back again and setting up the event again it is working normally now. So case closed for now, thanks.

Hi @joshuag, I'm noticing strange behaviour when I create a recurring event. For some reason the initial event occurs on the start date, but then another event is added the following day and all the recurrences are based on that second event. See the screenshots below where the intial event is set for a Tuesday and to recur every 7 days but the events recur on a Wednesday.

Welcome @FlorianA, There is module in the directory that provides a Inputfield/Fieldtype for picking and storing time values: http://modules.processwire.com/modules/inputfield-time/

If you mean the user sorts the new images before the form is submitted then you would add() the images to the field in the same order as they are arranged in your form and the order will be maintained. If you mean it is a two step process... The user uploads images and they are added to the field The images that are in the field are listed and the user sorts them and submits the new sort ...then you can use the key (which is the image filename) of each image in the Pageimages WireArray to identify it. Your form would send an array (say it's named 'images_sorted') with each filename as key and sort order integer as value. Then when you process the form you would get each image in the field by key and add a new property to the image to hold its sort order (there isn't actually an existing property called 'sort' but you can add one). Then you sort the field by that property as @Zeka suggested. $page->of(false); foreach($images_sorted as $key => $value) { $page->images->get($key)->sort = $value; } $page->images->sort('sort'); $page->save();

@nabo, I think you can just do some Pageimage resizing method on the last item in the field, which will be the image you just added. $product->setOutputFormatting(false); $product->images->add($file_url); $product->save(); // create variation of image $product->images->last->size(400, 300); // whatever resizing method you want

I think this is because as soon as you click "Add New" in a repeater inputfield a new as-yet-unpublished page is added to the repeater. So when you get the "old" page after saveReady this unpublished repeater item already exists and is included in count(). Try this: wire()->addHookAfter('Pages::saveReady', function($event) { $page = $event->arguments[0]; if($page->isChanged('repeater')) { $old_repeater_value = $this->pages->getById($page->id, array( 'cache' => false, 'getFromCache' => false, 'getOne' => true, ))->repeater->not('published=0'); // exclude as-yet-unpublished items bd($page->repeater->count, 'new count'); bd($old_repeater_value->count, 'old count'); } });

Hi @cosmicsafari, This has been answered here:

Hi @kongondo, I've been getting to know this module and it's really impressive the features you've worked in and all the settings that can be customised. Just wondering about the behaviour of the MM inputfield though - currently it reloads the whole of Page Edit with each addition to the field, which is not so good if the user has made some edits to other fields but not yet saved the page. They are faced with the option of accepting the reload which would lose the other field edits, or cancelling the reload in which case their media selection is not added. Maybe you could look at how the PageTable inputfield reloads itself via AJAX when a change is made, and do something similar with the MM inputfield?

I'm puzzled by the idea that the thumbnail part of the selector could change your sort order - by using thumbnail!='' we are saying that we don't want any pages that don't have a thumbnail (because in that case you can't show their thumbnail in the slide). So that will exclude some pages if there are any without a thumbnail, but it shouldn't change the sort order of the pages that are matched. If you are using my example that uses chunk() then remove this: // ditch the last group if it has less than the number of images per slide (assuming that's what you want) if( count(end($albums_chunked)) < $images_per_slide ) array_pop($albums_chunked); Or if you are using my second example then change the for() line to: for($n = 0; $n < $albums->count(); $n += $images_per_slide) {

@Juergen, thanks for the report - should be fixed in v0.0.4

The only thing affecting the order of the images is the sort within the selector. You can check the order right after you get the albums: $albums = $pages->find("parent=/work/, template=project, thumbnail!='', sort=sort"); echo $albums->each("<p>{title}</p>"); This should list the pages in the same order as they appear in the page tree. Unless you have specified automatic sort settings on the parent page or template, but I doubt you would have done that as it would prevent manually sorting the pages. If the album pages are listed in the right order but the images within each slide are not in the position you want then that is a CSS issue. Not sure what is going on there. There's nothing in the chunk() hook that should affect logging in. But you don't really need to add chunk() as a new WireArray method if it's causing you difficulties and you only need to use it for this one application - you can just do the equivalent within your template/include/function instead: $images_per_slide = 4; $albums = $pages->find("parent=/work/, template=project, thumbnail!='', sort=sort"); $albums_chunked = array(); for($n = 0; $n + $images_per_slide <= $albums->count(); $n += $images_per_slide) { $albums_chunked[] = $albums->slice($n, $images_per_slide); } // now iterate...

@jploch, looks like good case to use my proposed $wirearray->chunk() for. See this post for the hook you would need to add in order to use chunk()... I'm not a fan of echoing markup within functions (nothing wrong with it, just a personal preference) so I would do this: In a new include/partial named album_list.php... <?php $images_per_slide = 4; // exclude pages with no thumbnail in the selector $albums = $pages->find("parent=/work/, template=project, thumbnail!='', sort=sort"); // chunk albums into groups $albums_chunked = $albums->chunk($images_per_slide); // ditch the last group if it has less than the number of images per slide (assuming that's what you want) if( count(end($albums_chunked)) < $images_per_slide ) array_pop($albums_chunked); ?> <?php foreach($albums_chunked as $key => $slide): ?> <div class="slide" id="slide<?= $key + 1 ?>"> <div class="grid"> <?php foreach($slide as $album): ?> <a href="<?= $album->url ?>" <?= $album->thumbnail->bgset('half', 'lazyload item size1of2', array('quality' => 70)) ?>> <img src="/site/templates/img/plus-icon.svg" class="info-button"> <div class="item-info"> <div class="info-container-center"> <h3><?= $album->thumbnail->tags ?></h3> <h2>Für <?= $album->title ?></h2> <p><?= $album->thumbnail->description ?></p> </div> </div> </a> <?php endforeach; ?> </div> </div> <?php endforeach; ?> Then wherever you want to output the slides... include $_SERVER['DOCUMENT_ROOT'] . '/site/templates/partials/album_list.php'; Or if you prefer... echo $files->render('partials/album_list');

Depends how many roles you have, whether any of those non-superuser roles need admin access, whether you will be adding new roles in the future, etc. But in general if a role has no permission to edit pages then you could say they have no business accessing the admin, and that way you don't have to maintain some list of authorised/non-authorised roles.