Robin S

If the role doesn't have page-edit permission and doesn't have profile-edit permission then they cannot see the page list or edit their profile. They just see this: But to prevent them from seeing the admin interface at all you can add this at the top of /site/templates/admin.php... if($user->isLoggedin() && !$user->hasPermission('page-edit')) { // Uncomment whichever you prefer // $session->redirect('/'); // throw new Wire404Exception(); }

Are you talking about inputfield dependencies? From the docs...

Installing via "Add module from URL" is nearly as easy: https://github.com/somatonic/ClearCacheAdmin/archive/master.zip But I agree it would be great to have this module in the directory.

To my way of thinking, numeric IDs are the worst case in terms of being editor friendly. I see HannaCodeDialog as being a kind of progressive enhancement of Hanna Code, such that in the future you could uninstall HannaCodeDialog and still have tags that an editor can understand and use. But with numeric IDs you'll have tags along the lines of... [[my_tag file="34784" options="4745|9748|8985"]] And that seems contrary to the whole idea of Hanna Code, which is about giving editors easy to understand options while you the developer do the heavy lifting (be it matching editor-friendly names to IDs or whatever) behind the scenes in the tag code. Having said that, I'd like the module to be flexible and let devs decide for themselves how they want to use it. So happy to announce... HannaCodeDialog v0.1.2 Inserting a tag from the dropdown no longer opens the dialog if the tag has no editable options. A new method prepareOptions() can be hooked in order to define or manipulate the options that can be selected for a tag attribute. See the module readme for more. @LMD, you can hook this new method to set separate value and label as per your proposal: $wire->addHookAfter('HannaCodeDialog::prepareOptions', function($event) { $options = $event->return; $new_options = array(); foreach($options as $option) { if(strpos($option, '@@') !== false) { list($value, $label) = explode('@@', $option); $new_options[$value] = $label; } else { $new_options[$option] = $option; } } $event->return = $new_options; });

No, I mean cookies. I've experienced endless redirect issues when PW gets confused about my logged in status, perhaps due to the change of cookie name from "wire_challenge" to "wires_challenge" when accessing PW via the HTTPS protocol. Deleting the existing session cookies and logging in again solves the issue. The browser cache has no impact on your logged in status.

I agree this would be an improvement and will add it in the next release. I'm not opposed to adding this as such but I want to be sure that it's the best way forward. Besides making the module usage that bit more complicated, the issue to me is that the tag as it appears in the CKEditor window is readable text - a site editor can look at the tag and it makes some sense. If you display a different string of text in the dialog inputfield than what is inserted into the tag then I think this could be confusing for site editors. You are saying you have some options where there is a human-friendly label and a not-so-friendly value that you actually need for use inside the tag's code. Wouldn't it be better to only ever show the human-friendly label in the tag and dialog, and then match the label to the needed value inside your Hanna code? So if you, the developer, know that "file123-xyz.pdf" is aka "Annual Accounts 2016" then in your Hanna tag code you have something like: if($file == 'Annual Accounts 2016') $file = 'file123-xyz.pdf'; Of course you could use switch() for multiple cases, or look up filenames from the descriptions, or match the label to value in whatever way you would have done when assigning "value@@label" under your proposal. Does that make sense? Any other users have an opinion on this?

These redirects can be made by uncommenting two portions of the PW .htaccess file: One Two If you're seeing this when trying to access the PW admin then it could be due to old browser cookies - try clearing the cookies for your domain.

IMO having comprehensive documentation is something that can only add value to the Pro modules, and takes nothing away from them. I get that many users will only interact with the modules via the admin interface and would have no desire to browse through all the methods - they can ignore that documentation entirely. But it's nice to have thorough documentation for those who do have a need for it. I'm not proposing that you necessarily spend a lot of time writing up documentation beyond what's already present in the source. The tools already exist to extract and format those phpdoc comments as online documentation as it powers the current API reference docs. And the API Explorer module can do this for modules already. The reason I prefer online docs to the API Explorer is that it's so useful to harness the power of Google to find what you're looking for. It's quicker and more powerful to open a new browser tab and do a search from the address bar (I have a keyword shortcut for "site:processwire.com/api/ref/+%s") than navigating through the API Explorer interface. And of course not everyone has API Explorer. Could the Pro modules be stored in private GitHub repos and indexed the same way as the API reference? Maybe this module from @justb3a could be useful for the authorisation?

@horst, I can see how that upgrade would be difficult to do gracefully. Will post back if I have any ideas. Regarding CroppableImage3 and the ProcessWireUpgrade module: I think the reason why the upgrades module doesn't see available updates for CI3 is due to the module class name that is showing in the modules directory. The class name shown is "CroppableImage3" but I'm not sure where that comes from because it isn't actually a class name that is used in the modules (correct me if I'm wrong). Did you enter that manually? Or maybe it comes from the name of the GitHub repo? When the upgrades module queries the modules directory it is looking for the classnames... FieldtypeCroppableImage3 InputfieldCroppableImage3 ProcessCroppableImage3 ...but it doesn't find a match for any of these, therefore they are left out of the table of upgradable modules. Maybe it would be best to follow the example of several of the other fieldtype modules, where the primary name of the module would be FieldtypeCroppableImage3 even though it auto-installs two other modules.

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' ]);