Robin S

Would you mind making the README available to prospective purchasers? Likewise the README for Media Manager?

For images in an images field, you can create any sizes you need via PW's native resizing methods. For images inside an RTE field you can use a textformatter module. The idea would be to detect images in the RTE block and replace them with your own custom srcset markup. The Image Interceptor module is a good one to look at if you want to get ideas for a custom module. But there is already the TextformatterImageSRCSET module ready to go. And also check out the ImageToPicture module.

Rather than define a parent for selectable pages in your page field, try the "Custom PHP code to find selectable pages" option... return $pages->find("parent=/clients/{$this->user->name}/categories/");

@BitPoet: Incidentally, one reason I thought a sister "Page Child Templates" module would be useful is that it avoids any potential difficulties there might be in extending the "Add New" feature (which normally requires allowed templates to be configured for both parent and child templates, although it's not clear to me why the parent template restriction on children is logically necessary for this feature). If it were possible to specify for a given page what template(s) may be used for child pages then the Page Add Bookmarks feature could be used in place of the original "Add New" feature. The Page Add Bookmarks feature just adds a page under a given parent in the tree, but if a "Page Child Templates" module has locked down allowed templates for that parent then you have a pretty foolproof substitute for "Add New" without having to add extra unnecessary templates for those parent pages. My understanding of the relationships required is pretty limited, but looking at your code for the Template Parents module it looks like it could be adapted for a Page Child Templates module. The way I imagine it working is that for any page that has allowed templates for children configured, the module stores a row in a database table containing allowed template IDs for that page ID. Then when a new page is added, the filterAllowedParents function hooked to ProcessPageAdd::getAllowedTemplates filters the list of allowed templates according to any template IDs that are stored for the new page's parent page ID. But I might be overlooking some complexity here. I'll probably have a tinker with your Template Parents module to see if I can adapt it myself but I'm a bit of an amateur.

Loving this module - perfect for a site I'm currently developing. Just noticed a bug: allowed parents selected from Setup > Templates > Edit Template are not saved successfully (no selection is saved). Allowed parents selected from Setup > Template Parents are saved okay. Another thought: how about a sister module for Template Parents, "Page Child Templates"? So for any page you can define allowed templates that may be used for child pages. Now I'm just being greedy

I'm thinking of the same "Add New" functionality you get when you use the core "Allowed template(s) for parents" + "Allowed template(s) for children" + "Show in the add-page shortcut menu" options. It lets you add a new page of a particular template in one step because PW "knows" where in the tree a page of that template is allowed to go. In theory this functionality could also apply to templates with a parent page restriction defined with your module, but I'm not sure how difficult it would be to extend the Add New functions to allow for this.

Thanks for the replies. @elabx: Yeah, I'm already doing a similar workaround using the ->not method. $page_array_1 = $pages->find(selector_1); // do some stuff with $page_array_1 $page_array_2 = $pages->find(selector_2); // do some stuff with $page_array_2 // then to subtract $page_array_1 from $page_array_2... $page_array_2->not(selector_1); But it seems wrong to have to use the same selector again when you already have the PageArray you want to remove. I figured there has to be a better way... ...and there is, but it's not in the docs or cheatsheet. Thanks BitPoet.

There is a remove method for WireArray/PageArray that removes a single given item from the array. But how about removing all the items in one PageArray from another? So basically like PHP's array_diff for PageArray - any suggestions for this?

BitPoet, many thanks for this module! When attempting to go to the settings page for Template Parents Process in PW v2.7.2 I get an error: "Undefined index: inheritSettings in ...\site\modules\TemplateParent\ProcessTemplateParents.module on line 232" Also, do you think there's a way to have templates that have been given a parent page restriction with this module appear in the "Add New" menus?

Superb!

Often I want to limit the placement of pages with a particular template to a particular parent page in the tree. Many times this parent page doesn't need to have it's own unique template, but I end up duplicating one of my existing templates (lets say it is "basic-page") just to make sure editors don't have the ability to mess up the placement of pages, and so I can make make use of the "Add New" shortcut. So I end up with "basic-page" and duplicates "basic-page-2", "basic-page-3", etc (naming is just for argument's sake). When templates are duplicated the problem isn't so much the template files, because it's easy to manually assign the file of basic-page to basic-page-2 and basic-page-3. The problem is maintenance - if I want to add a field to basic-page, change a label or field width override, etc, I now have to repeat these changes on multiple templates. It becomes difficult to keep the duplicated templates in sync. Having a template setting "Allowed page id(s) for parent" would avoid the need to duplicate templates in this situation. An alternative possibility is some system of template inheritance, but that's another kettle of fish.

Got it sorted, and complete plugin code is: // Keyboard shortcuts for headings 1-6, p ( function() { CKEDITOR.plugins.add( 'keystrokes', { init: function( editor ) { editor.addCommand( 'h1', { exec: function( editor ) { var format = { element: 'h1' }; var style = new CKEDITOR.style(format); style.apply(editor.document); } } ); editor.addCommand( 'h2', { exec: function( editor ) { var format = { element: 'h2' }; var style = new CKEDITOR.style(format); style.apply(editor.document); } } ); editor.addCommand( 'h3', { exec: function( editor ) { var format = { element: 'h3' }; var style = new CKEDITOR.style(format); style.apply(editor.document); } } ); editor.addCommand( 'h4', { exec: function( editor ) { var format = { element: 'h4' }; var style = new CKEDITOR.style(format); style.apply(editor.document); } } ); editor.addCommand( 'h5', { exec: function( editor ) { var format = { element: 'h5' }; var style = new CKEDITOR.style(format); style.apply(editor.document); } } ); editor.addCommand( 'h6', { exec: function( editor ) { var format = { element: 'h6' }; var style = new CKEDITOR.style(format); style.apply(editor.document); } } ); editor.addCommand( 'p', { exec: function( editor ) { var format = { element: 'p' }; var style = new CKEDITOR.style(format); style.apply(editor.document); } } ); editor.setKeystroke( CKEDITOR.ALT + 49 , 'h1' ); // ALT + 1 editor.setKeystroke( CKEDITOR.ALT + 50 , 'h2' ); // ALT + 2 editor.setKeystroke( CKEDITOR.ALT + 51 , 'h3' ); // ALT + 3 editor.setKeystroke( CKEDITOR.ALT + 52 , 'h4' ); // ALT + 4 editor.setKeystroke( CKEDITOR.ALT + 53 , 'h5' ); // ALT + 5 editor.setKeystroke( CKEDITOR.ALT + 54 , 'h6' ); // ALT + 6 editor.setKeystroke( CKEDITOR.ALT + 55 , 'p' ); // ALT + 7 } }); } )(); After adding the plugin it needs to be activated in the field settings > Input > Extra Plugins keystrokes.zip

Thanks! That plugin code works perfectly for all the basic commands. Unfortunately I'm having trouble finding the names of commands for items in the Format dropdown (headings 1-6, paragraph, etc). That's really a CKEditor problem rather than a PW problem. Will post the solution here if I can find one.

The code above is from the docs for CKEditor v3, so that's not applicable. The v4 docs give the following example... editor.setKeystroke( CKEDITOR.CTRL + 115, 'save' ); // Assigned Ctrl+S to the "save" command. editor.setKeystroke( CKEDITOR.CTRL + 115, false ); // Disabled Ctrl+S keystroke assignment. editor.setKeystroke( [ [ CKEDITOR.ALT + 122, false ], [ CKEDITOR.CTRL + 121, 'link' ], [ CKEDITOR.SHIFT + 120, 'bold' ] ] ); ...but I'm still not sure where this should be added to be applied in PW's CKEditor module.

CKEditor doesn't provide shortcut keys for applying headings 1-6 and this makes text formatting slower than it needs to be. I'd like to add shortcuts for headings but I'm not sure where the config code should go. The CKEditor docs for shortcut keys give the following example: Edit: wrong version, see next post // This is actually the default value. config.keystrokes = [ [ CKEDITOR.ALT + 121 /*F10*/, 'toolbarFocus' ], [ CKEDITOR.ALT + 122 /*F11*/, 'elementsPathFocus' ], [ CKEDITOR.SHIFT + 121 /*F10*/, 'contextMenu' ], [ CKEDITOR.CTRL + 90 /*Z*/, 'undo' ], [ CKEDITOR.CTRL + 89 /*Y*/, 'redo' ], [ CKEDITOR.CTRL + CKEDITOR.SHIFT + 90 /*Z*/, 'redo' ], [ CKEDITOR.CTRL + 76 /*L*/, 'link' ], [ CKEDITOR.CTRL + 66 /*B*/, 'bold' ], [ CKEDITOR.CTRL + 73 /*I*/, 'italic' ], [ CKEDITOR.CTRL + 85 /*U*/, 'underline' ], [ CKEDITOR.ALT + 109 /*-*/, 'toolbarCollapse' ] ]; And the advice is that the code belongs in "plugins/keystrokes/plugin.js", but I suspect that isn't correct for PW because this file doesn't exist in the CKEditor module yet the normal keyboard shortcuts are available in PW. Which makes me think the keyboard shortcuts are defined somewhere else. The other place I thought of adding the config code is in the Custom Config Options textarea in the field settings, but the example code looks like it doesn't conform to property: value format for this field.

Thanks for the ideas. @mr-fan: I think this might be the sort of thing you're hinting at - at the top of the widget templates... <?php if( empty($options['pageStack']) ) throw new Wire404Exception(); ?> Good info in this post from Jonathan Lahijani here and some info on pageStack from Ryan here. I like this solution. @LostKobrakai: Sounds like this would work, but it seems to me there are downsides to using wireRenderFile() over $page->render(). I have a lot of different widget templates and widgets are selected by editors via a page field, so using $page->render() keeps the rendering code really simple and maintenance-free. foreach($page->widgets as $widget) { echo $widget->render(); } But if I use wireRenderFile() I need a whole chain of logic to check the template of each widget and render it with the correct file for that type of widget. Besides avoiding partial pages being directly viewable, are there other benefits of wireRenderFile() that make it preferable to $page->render()?

I have some pages that are used only as partials, to be rendered as part of other pages using $page->render() I have them inside a /widgets/ branch in my page tree. The problem is that they are viewable from the front-end: if someone visits mydomain.com/widgets/my-widget/ they see the partial HTML. Is there a way I can keep my widgets accessible to editors in the back-end and capable of being rendered in other pages but without them being directly viewable?

You are right of course, don't know what I was thinking there... So I think we can safely say that of the two, ->has() definitely performs better

Which of the following is the better way to test if a PageArray contains a particular id? $my_page_array->has("id=1234") or $my_page_array = 1234 Does one perform better than the other?

Yes please!

This can be set in My Settings > Notification Options...

I think you're right, but it's more a case of "will be solved" rather than "can be solved" because the module isn't available yet. Eagerly looking forward...

You could check with your host to see if they are running mod_security. I just struck the same 404 problem when I use an include in my Hanna PHP code. My host lets me disable mod_security via htaccess, and sure enough when I disable it the 404 problem is gone.

Perhaps try the Dynamic Roles module.

It occurred to me that a good addition to the forums would be some way for PW users to indicate support for a module idea. Similar to the Wishlist subforum but for functionality that belongs in a module rather than in the core. I'm thinking mainly of commercial modules, although if someone wanted to take up a module request and release it freely that would be cool. So users could propose a module idea, then others would vote for it (using likes or some special voting option) so that a vote means "I'd buy that", with the expectation of pricing in the general ballpark of Ryan's pro modules and Apeisa's PadLoper. As a beginner-intermediate developer I'm really enjoying working with PW and learning as I go - the API is so intuitive that I've been able to build my own solutions to things that in another CMS I would have been reliant on someone else's module to achieve. But there are things that I know are beyond my current skills, and for those things I look to third-party modules. My clients are non-profits and small businesses so I'm never likely to have the budget to commission a custom module alone. But there might be other PW users out there with similar needs and maybe that demand would make it worthwhile for an experienced developer to take on a proposal and release it as a commercial module. Currently there isn't a way to measure the demand for modules apart from occasional forum posts like "Is there a module that...?" Any thoughts on this? Here's a module request to start off with: I would be happy to buy a full-featured event calendar module. I've searched the module directory and the forums and Lindquist's module is the most feature-rich I've seen, but it's in an alpha proof-of-concept state and some important functions aren't implemented. Features I would be looking for are: Calendar grid interface in admin, allowing for easy addition and editing of events. (Nice but non-essential) Week and day views in admin, in addition to month view, with drag editing for event date and duration (I'm dreaming of something awesome like the dhtmlxScheduler interface or Fullcalendar interface). Although drag operations would really need an undo to correct accidental edits, so this may be more trouble than it's worth. Events are edited in a modal window, to avoid losing one's place in the calendar. Recurring events, with user-friendly selection of recurrence options. The ability to individually edit or remove an event that is a child of a recurring event (i.e. make an exception for that individual event). (Nice but non-essential) A couple of out-of-the-box minimal rendering options for the frontend (read-only calendar view, list view). This is the kind of module I need frequently. I've been lucky that I haven't had a client request a full event calendar since I've been using PW, but it's only a matter of time. I'm sure there are other PW users who need this and who would, like me, be happy to pay for such a module.