Robin S

I don't agree - those are separate settings and a user might want to define separate formatting for each. But you are free to define the same formatting for both if you like: Setup > Fields > [your page reference field] > Input > Custom page label format Setup > Templates > [your template] > Advanced > List of fields to display in the admin Page List

Hi @horst, I tried out this module today and it's nice, thanks. But the installation process and the PIM1/PIM2 thing was clear as mud to me - I got it worked out in the end but I don't understand why the module is set up that way. I get the need for different module versions according to which PW version you are running, but couldn't PIM1 and PIM2 be separate modules be in separate GitHub repos and you just install the one you want? Or better - could there just be a single module that checks the PW version number and uses the right code for that version? That way pimLoad() and pimSave() wouldn't have to be renamed and choosing/installing/using the module would be simpler for the user.

Consider switching to the Pageimage Manipulator module, which has a canvas() method that supports the image resizing you are doing. I don't see any reason why the imagickal() function would be the cause of the problems you are having, but horst knows a lot more than I do and his module is likely to be better optimised.

Custom format is working normally for me in a Page Reference select field in 3.0.62. This also works for me. Are you sure the 'something' Page Reference field you are using in the custom format returns a single page? If it returns a PageArray then I would expect this not to work.

I think the pagination behaviour with $pages->find("sort=random") is unexpected and so have opened a GitHub issue. Looking at the PageFinder source code it isn't difficult to see how a seed could be used with the random sort, but the relevant method isn't hookable so any fix will require a core change.

Cool, I haven't looked at that method before. But it only works with a PageArray/WireArray so not ideal if you have thousands of pages to sort. Would be good if there was something similar for PageFinder.

@ryan, you mentioned Pro module updates in this week's post. When you're working on the pro modules it would be great if you could give the pro module documentation some attention. The documentation that does exist is only in the pro module subforums and the forum post format doesn't provide a good interface for browsing or searching individual module methods or for formatting the documentation and code examples. It is much inferior to the current core API reference docs, which doesn't seem right considering the pro modules are premium commercial products. Keeping the documentation in the pro forums also has the effect that if a pro module purchaser does not renew their support/upgrade license then they are cut off from the documentation. Not that cost of ongoing support/upgrades is unreasonable (your pro modules are fantastic value for money) but I think the essential documentation should always be available to pro module purchasers. A third-party pro module was launched today and the presentation of its features and documentation is excellent. This got me thinking about the issue.

Wow, this looks amazing! I've been wishing someone would make a full-featured PW calendar module for a while now and this looks like it fits the bill. So thanks! A question: it looks like it's possible to disable an occurrence of an event, but is it possible to create a one-off variation of an occurrence? For example, if there is a weekly yoga class on a Tuesday but on one particular week it has to move to Wednesday, can I locate that occurrence and edit it individually? Similar to this, from Lightning calendar... P.S. the links on the 99lime.com home page to "Responsive Menu" and "ProcessWire Go" are non-functional.

@Roych, you might find it easier to stick with your original event markup (i.e. as primarily HTML) rather than echoing the entire event markup in PHP. You can switch in and out of PHP as much as you like, and treat PHP similar to how you would work with a template language like Twig or Smarty: <?php $events = $pages->find('template=calendar-post, limit=8, Start_date>=today, sort=Start_date'); ?> <?php if(count($events)): ?> <?php foreach($events as $single): ?> <!-- Event --> <li> <div class="date"> <span> <span class="day"><?php echo strftime("%d", strtotime($single->Start_date)); ?></span> <span class="month"><?php echo strftime("%h", strtotime($single->Start_date)); ?></span> <span class="year"><?php echo strftime("%Y", strtotime($single->Start_date)); ?></span> </span> </div> <div class="event-content"> <h6><a href="<?=$single->url?>"><?=$single->title?></a></h6> <ul class="event-meta"> <li><i class="fa fa-clock-o">&nbsp;&nbsp;</i> <?php echo strftime("%H:%M", strtotime($single->Start_date)); ?>^{<?= $out = __("h"); ?>}</li> <li><i class="icons icon-location"></i> 340 W 50th St.New York</li> </ul> </div> </li> <!-- /Event --> <?php endforeach; ?> <?php else: ?> <p>No upcoming events at this time!</p> <?php endif; ?>

Hi @rick, I can't share my custom profile because it contains pro modules. And it's set up to suit my preferences and idiosyncrasies which would surely be different for each person. But it's very easy to make your own custom profile. If you find yourself installing the same modules or creating the same kinds of page structures over and over for each project then the idea is: Create a new installation on your localhost using the "blank" profile Customise /site/config.php how you like, e.g. imageSizerOptions, useMarkupRegions, setlocale() Install your favourite modules - include the Site Profile Exporter Set up any admin tweaks with AdminOnSteroids and/or AdminCustomFiles Create the fields, templates and template files you tend to need for every new site (it doesn't hurt if there are some that aren't always used as you can always delete them in any project that doesn't need them) Create any page structures you want to have pre-existing (I have a "news" section, and a "selects" section for Page Reference options) Export your site profile Then when you are creating a new project you just copy the profile folder to the root before installing PW and select it during the install process. I keep my starting profile on localhost and update/re-export it from time to time with the latest module upgrades and any new tricks and tweaks I have learned.

There may be other solutions but this is what I do...

It helps the community if people share the solutions to their problems Could you please post back with what you found? Thanks.

I tried the module a bit in PW3 and it works well - it's a really handy module and I wish I started using it sooner. I think the permission overrides per template only apply to the sub-permissions of page-edit (page-move, page-delete, etc) and these won't affect the module because those sub-permissions aren't displayed in the tables. One issue I came across is that where a template has a numeric name ("404" being an obvious one) the edit link to the template is not displayed properly in the table. Have created an issue on GitHub with a proposed fix. I also thought that where the the 'muted' class is used the text colour is too faint.

The example uses the selector arrays feature so you would make your change like this: 'roles' => ['agent', 'superuser']

There's always a solution First thing to understand is that the access control that is built into the PW core is based around templates, not around pages. So if you have given a role permission to add children for a template then a user with that role can add children to any page with that template. Or if you have allowed permissions to be inherited then a role might inherit the add children permission from the template of a parent page you have granted it on. Same goes for any other access permission. But that is only the PW core - you can modify the way permissions work with your own hooks or by using existing modules. A couple of modules that might suit your needs: AdminRestrictBranch: If your users only have permission to work with a particular page and children of that page then this module might be ideal because it can hide everything outside of that branch. UserGroups: Another module that implements page-based permissions. I haven't used this module but apparently it is pretty stable despite the "alpha" label in the support thread. You might need to tweak a couple of things to get it working smoothly in PW3 - see this and this. And a third option... You don't make this clear in your original post but I take it you have installed the PageEditPerUser module. This module allows you to define individual pages that a user may edit but it doesn't get involved with the permission to add children. However you could edit the module to include a hook to Page::addable public function init() { $this->addHookAfter('Page::editable', $this, 'hookPageEditable'); $this->addHookAfter('Page::viewable', $this, 'hookPageViewable'); // fixing a long-standing typo in the module $this->addHookAfter('Page::addable', $this, 'hookPageAddable'); // the new addable hook } // ... public function hookPageAddable($event) { if($event->return) return; $event->return = $this->onMyBranch($event->object); } Now child pages may only be added to pages that the user has been given edit access for in their user profile.

@Arcturus, isLoggedIn() only works for the current user. There is a related thread here which suggests adapting some code from the SessionHandlerDB module to get active users from the database. I updated/modified it a bit below: // Find IDs of users that have been active in the last $mins number of minutes function onlineUserIDs($mins, $limit = 500) { $table = SessionHandlerDB::dbTableName; $seconds = $mins * 60; $sql = "SELECT user_id " . "FROM `$table` " . "WHERE ts > DATE_SUB(NOW(), INTERVAL $seconds SECOND) " . "AND user_id!=40 " . // exclude guest "ORDER BY ts DESC LIMIT $limit"; $query = wire('database')->prepare($sql); $query->execute(); $results = $query->fetchAll(\PDO::FETCH_COLUMN); return $results; } $online_user_ids = onlineUserIDs(60); // User IDs active in the last hour // Online users $online_users = $pages->find([ 'id' => $online_user_ids ]); // Offline users $offline_users = $pages->find([ 'id!=' => $online_user_ids, 'template' => 'user', 'roles!=' => 'guest' ]);

@Slav, you might find this module useful for understanding user permissions across your templates: https://modules.processwire.com/modules/process-access-overview/

This finds all 'articleFeatured' articles, but you only need one. So better to do this: $latestArticle = $pages->findOne("template=article, articleFeatured=1, sort=-created"); I wrote that imagickal() function and it doesn't recreate the image on every page load if the processed image already exists. But it was really intended for applying ImageMagick effects - you don't need it for simple image resizing. Rather than add padding in the resized image you should use CSS to keep the image within its container while maintaining aspect ratio. A couple of ways you can do this below - CSS is inline in the examples but you would move it to an external stylesheet. If you don't mind using background images the technique is dead simple. Just adjust the padding-top for the desired aspect ratio (in the example I used your 730:350 ratio). <div style="padding-top:47.945%; background:#000 url('my-image.jpg') no-repeat center center / contain;"></div> If you want to use an <img> tag there's a bit more to it: <div style="padding-top:47.945%; position:relative;"> <div style="position:absolute; width:100%; height:100%; top:0; left:0; font-size:0; line-height:0; text-align:center; background-color:#000"> <img src="my-image.jpg" style="max-width:100%; max-height:100%;"> </div> </div> If you are using a CSS pre-processor you can use a helper mixin, e.g. https://css-tricks.com/snippets/sass/maintain-aspect-ratio-mixin/ But none of this should make that much of a difference when you are using ProCache - your server load should be very low when ProCache is used considering you have no front-end users logging in. You could check to make sure you are not clearing the entire cache unnecessarily - for best performance you shouldn't use the "Reset cache for entire site" option for when a page is saved but instead use the settings on the "Cache" tab of Edit Template to only clear the cache of related pages. But the other thing to consider is if the problem might be due to the host. You could copy the files and DB to a different host and trial that for a bit to see if the problem resolves. A hassle for sure but if you are getting desperate...

I'm not sure what you mean here. There is no prefix to field names that are used in a repeater. For example, if you have the "title" field in your containing page template, and also the title field in your repeater template then the field name "title" applies to both without any prefix. echo $page->title; // the containing page title echo $page->my_repeater->first->title; // the first repeater item's title Or do you mean that in Page Edit the inputfields inside a repeater have a suffix to their name, e.g. "title_repeater1147"? Because you don't need to use that when you get the field in your template.

Yes, there is such an action: PageActionSetStatus

@Zeka's suggestion is the right direction, but a couple of extra things are needed: $your_pages = $pages->find("template=some_template"); foreach($your_pages as $p) { // Output formatting must be off before manipulating and saving the page $p->of(false); // You need to get the formatted value of the markdown field // i.e. with the textformatter applied $p->ckeditor_field = $p->getFormatted('markdown_field'); $p->save(); } Or a shorter way that takes care of the output formatting using setAndSave(): $your_pages = $pages->find("template=some_template"); foreach($your_pages as $p) { // Normally you wouldn't want to save a formatted value with setAndSave() // but in this case we do $p->setAndSave('ckeditor_field', $p->markdown_field); }

I think OR-groups with selector arrays is buggy: I opened a GitHub issue here.

You can avoid some repetition and shorten the way you get field content in your templates like this: // Get the repeater item (the item is a page) $r_item = $page->repeater_field->first(); // Get field content from the item echo $r_item->foo; echo $r_item->bar; echo $r_item->baz;

You probably already know this, but the buttons on the download page just link to the current state of the files in the master and dev branches. You can download at any time and get the latest commits regardless of what version number is shown on the button.

Only if you have already installed it, and this module is not installed by default.