Leaderboard

My current grid system is this, based on inuit.css's layout object: Include the mixins and some media queries (99% only for updating the width) and most grids are done.

On mobile... There is a setting in the admin (access tab) If you select 'Yes' you can define what roles have access to pages using this template. If you select 'No' then pages using this template will inherit access from their parent pages.

new site for photographer Nick Graham working with design agency Each. http://nickgraham.co.uk/

The future: grid layout and flexbox (use it today with polyfill)

You mean 'thank you'....

Available from the Modules Directory: http://modules.processwire.com/modules/front-end-edit-lightbox/

http://getuikit.com/docs/flex.html

$largePargeArray->removeItems($subsetPageArray); should work as PageArray inherits from WireArray.

A feature request here in the forums prompted me to shape a piece of code I had been tinkering with into a usable module. Template Parents What it does: The list of possible templates for new pages in ProcessWire is purely based on other templates in parent/child relationships managed in the involved templates' family settings. This is most often okay, but sometimes you want to limit creation of pages with a certain templates to individual spots in the page tree, and there's no clear parent/child relationship to go with. The initially quick solution would be to duplicate parent templates for the different spots, but then any change on one of these templates has to be made to the others too, which gets tedious and error prone. Template Parents adds an entry in the Setup menu where you can assign allowed parent pages to templates. These rules are enforced after the regular family settings have been executed, so it builds upon instead of replacing PW's built-in mechanism. There's also an option in ProcessTemplateParents' to enable inheritance, then entries in the Template Parents assignment are inherited down the page tree and also grant template permissions to children, grandchildren and so on. The module can be downloaded from the GitHub repository. It has been tested with PW 2.7 and 3.0.

Today I want to share a little module that adds 2 additional save buttons with redirect and 1 unpublish button to the page edit. 2 additional save buttons: My intention was that it would be nice if someone saves an article in the backend and will be redirected after saving directly to the frontend page of the article. This module adds 1additional save button at the bottom next to the default save button and 1 at the top. So you can choose if you want to save the article with the default save button or you will save it with the custom save button and you will get redirected to the frontend article. 1 unpublish button: The idea behind this was that I want to disable the setting tab for non superuser. The problem was if I hide it, then non superusers are no longer able to unpublish an article. Therefore this module adds an additional unpublish button at the bottom - the user clicks it and the page will be saved with status unpublished. All pages under the admin section will not be affected of this module. Module is multilingual, so you can set the button texts in all languages. Top view page status published: Bottom view page status published: Bottom view page status unpublished: Here is the code: <?php /** * Adding 2 additional save buttons with redirect to frontend and 1 unpublish button for page edit form. * * ProcessWire 2.x * Copyright (C) 2010 by Ryan Cramer * Licensed under GNU/GPL v2, see LICENSE.TXT * * http://www.processwire.com * http://www.ryancramer.com * */ class CustomPageSaveAndUnpublish extends WireData implements Module { /** * getModuleInfo is a module required by all modules to tell ProcessWire about them * * @return array * */ public static function getModuleInfo() { return array( 'title' => 'Custom page save and unpublish module', 'version' => 1, 'summary' => 'Example for adding 2 additional save buttons with redirect and 1 unpublish button to page edit', 'href' => 'http://www.processwire.com', 'singular' => true, 'autoload' => true ); } /** * Initialize the module * * ProcessWire calls this when the module is loaded. For 'autoload' modules, this will be called * when ProcessWire's API is ready. As a result, this is a good place to attach hooks. * */ public function init() { $this->addHookAfter("ProcessPageEdit::buildForm", $this, "addSaveButton"); $this->addHookAfter("ProcessPageEdit::buildForm", $this, "addUnpublishButton"); // tell processwire that this is a page save if ($this->input->post->submit_save_minor) { $this->input->post->submit_save = 1; // attach hook on page save $this->addHookAfter("Pages::saved", $this, "hookPageSave"); } if ($this->input->post->submit_unpublish) { $this->input->post->submit_save = 1; // attach hook on page save $this->addHookAfter("Pages::saveReady", $this, "hookPageSaveReadyUnpublish"); } } public function hookPageSave($event) { //function to redirect to the frontend after save $page = $event->arguments("page"); if ($this->input->post->submit_save_minor) { // this will get saved after this saveReady hook so no need to save here $pageid = $page->id; $goto = wire("pages")->get("id=$pageid")->url; //get url of frontend article wire("session")->redirect($goto); } } public function hookPageSaveReadyUnpublish($event) { //function to change the status to unpublished $page = $event->arguments("page"); $status = $page->status; $unpublishmessage = __("Status of the page is set to unpublished"); if ($this->input->post->submit_unpublish) { if ($status == 1) { $page->status = "2049"; $this->message($unpublishmessage); } } } public function addSaveButton($event) { //function to add the 2 additional save button with redirect at the top and at the bottom $page = $event->object->getPage(); $status = $page->status; if (($page->rootParent->id != "2") AND ($status == 1)) { //dont show on all pages which are under the admin section and which are not published $form = $event->return; $buttontext = __("Save and go to page"); // new submit button $f = $f2 = $this->modules->InputfieldSubmit; $f->attr("name", "submit_save_minor"); $f->attr("value", $buttontext); $f2->attr("name", "submit_save_minor"); $f2->attr("value", $buttontext); $f2->class .= ' ui-priority-secondary head_button_clone'; // add submit button after the regular save button only if page is published $form->insertAfter($f, $form->get("submit_save")); $form->insertAfter($f2, $form->get("submit_save")); } } public function addUnpublishButton($event) { //function to add the unpublish button at the bottom if page has status published $page = $event->object->getPage(); if ($page->rootParent->id != 2) { //dont show on all pages which are under the admin and dont show the button under the delete tab $form = $event->return; $unpublishbuttontext = __("Unpublish"); // new submit button $f = $this->modules->InputfieldSubmit; $f->attr("name", "submit_unpublish"); $f->attr("value", $unpublishbuttontext); // add unpublish button after the save button if ($page->status == 1) { $form->insertAfter($f, $form->get("submit_save")); } } } } Everybody who is interested can download the modul here: CustomPageSaveAndUnpublish.zip Best regards Jürgen

The new matrix field lists out the action buttons (e.g. add text, add quote, etc.). The buttons quickly run out of real estate. It's not very scalable. I would like to suggest that we have one action button, maybe just 'add' which upon clicking reveals all the available repeater items (e.g. text item, quote item, etc.). Consider the animated gif shown at the address below (taken from a page builder plugin for one of my other favorite CMS). https://github.com/TimOetting/kirby-builder Thoughts?

I think squeezing them in dropdown would optimize the UI for edge case, instead of the most common ones (1-5 options). That might be nice additional module, but I think current default works better in most cases.

Few things that might be affecting (all from here https://processwire.com/api/multi-language-support/multi-language-fields/#how-language-fields-work). foreach($page->artists as $c) { $c->of(true); // Output formatting needs to be on for multilang $user->language = $languages->get("french"); // replace "french" with some langname you have echo $c->body; echo {$user->language->title}; } Try above and if it works then you might find the problem.

This is sweet. And sooo easy to add to any PW site. http://blog.watchandcode.com/2016/03/17/the-single-piece-of-javascript-on-hacker-news/

Just switched from Neat to Susy in the current project because I was fed up with not able to accomplish a few simple things in Neat (of course, it may be that I was doing things the wrong way). The good thing was that it took about 10 minutes to swap the grid as there was no grid classes in the markup. This reassured me that grid classes in the markup is not necessarily a good decision. So far I'm fine with Susy, seems more logical to me.

Thank you for the module, it helped me understand how to create an additional button to add extra actions...

(Untested) It should be sufficient to assign the correct value for parent (the User class inherits from Page) and pass the correct template in the constructor. $u = new User($templates->get('my-user-parent')); // pass the Template object $u->parent = 222; // you can also pass a Page object or selector string here // continue as usual...

You guys have to do it through Google translate. I'll give you something straight from the target audience of this update. ПроцессВаир теперь поддерживает кириллические урлы! С сегодняшнего дня сайты в зоне .рф можно полноценно создавать на этой замечательной системе. Благодарим Райана за заботу. Ура, товарищи!

Update: Latest release and documentation is available here: https://github.com/rolandtoth/FrontEndEditLightbox Modules directory: http://modules.processwire.com/modules/front-end-edit-lightbox/ ----------------------------------------------- Just implemented my front-end edit feature, minimal style I know there's many other solution to this but I tried making something much simpler to implement. The result is one JavaScript snippet - no css, external js dependency, module, etc. It uses the admin's Magnific Popup because it's always at hand and works just fine. The page automatically reloads on closing the lightbox, but only if the page was saved (via localStorage). You can also list jQuery selectors to hide items in the admin (see "selectorsToHide"). Usage Add the edit link to your template file (see code below) and copy the following to your main .js file.

Follw up with my previous post https://processwire.com/talk/topic/12782-regarding-multiple-templates-or-parents-for-users/ For default installation, api to create a new user is something like that $u = new User(); $u->of(false); $u->name = "adrian"; $u->email = "adrian@example.com"; $u->pass = "123456"; $u->addRole("registered"); $u->save(); $u->of(true); With multiple template or parent , how to setup a user object to use which template and parent, before executing save() method ?

I recommend using kongondo's ApiGen Docs, for example 3.x: http://kongondo.github.io/ProcessWireAPIGen/devns/class-PageArray.html Ryan's doc pages should be considered "for introduction purposes only". We cannot expect him to keep it up-to-date

Just had to do a quick head scratch to get the colour picker to work inside PW 3.12 Repeater and Repeater Matrix. If anyone is looking for a very quick and dirty hack, that seems to work. Not sure if it would cause any other issues. This is InputfieldFontIconPicker.js function SetUpCPicker(){ $('div[id^=ColorPicker_]').each(function(){ var $colorpicker = $(this); $colorpicker.ColorPicker({ color: $(this).data('color').toString(), onShow: function (colpkr) { $(colpkr).fadeIn(500); return false; }, onHide: function (colpkr) { $(colpkr).fadeOut(500); return false; }, onChange: function (hsb, hex, rgb) { $colorpicker.css('backgroundColor', '#' + hex); $colorpicker.css('background-image', 'none'); $colorpicker.next('input').val(hex).trigger('change'); } }); }); $('a.ColorPickerReset').on('click',function(e){ e.preventDefault(); var color = $(this).data('default') && $(this).data('default') != 'transp' ? '#' + $(this).data('default').toString() : 'transparent'; $(this).parent().find('input').val($(this).data('default')).trigger('change'); $(this).parent().find('div[id^=ColorPicker_]').ColorPickerSetColor($(this).data('default').toString()); $(this).parent().find('div[id^=ColorPicker_]') .css('backgroundColor', color) .css('background-image', 'none') .attr('data-color', $(this).data('default').toString()); if(color == 'transparent') { var modurl = $(this).data('modurl'); $(this).parent().find('div[id^=ColorPicker_]') .css('background-image', 'url(' + modurl + 'transparent.gif)'); } }); /* additions (swatches) by @Rayden */ $('div.ColorPickerSwatch').on('click',function(e){ e.preventDefault(); var color = $(this).data('color') && $(this).data('color') != 'transp' ? '#' + $(this).data('color').toString() : 'transparent'; $(this).closest('.ui-widget-content, .InputfieldContent').find('input').val($(this).data('color')).trigger('change'); $(this).closest('.ui-widget-content, .InputfieldContent').find('div[id^=ColorPicker_]').ColorPickerSetColor($(this).data('color').toString()); $(this).closest('.ui-widget-content, .InputfieldContent').find('div[id^=ColorPicker_]') .css('backgroundColor', color) .css('background-image', 'none') .attr('data-color', $(this).data('color').toString()); if(color == 'transparent') { var modurl = $(this).closest('.ui-widget-content, .InputfieldContent').find('.ColorPickerReset').data('modurl'); $(this).closest('.ui-widget-content, .InputfieldContent').find('div[id^=ColorPicker_]') .css('background-image', 'url(' + modurl + 'transparent.gif)'); } }); }; $(document).ready(function() { SetUpCPicker(); $(document).on('repeateradd', '.InputfieldRepeaterMatrix .InputfieldRepeaterMatrixAddLink', SetUpCPicker); $(document).on('opened', '.InputfieldRepeaterItem', SetUpCPicker); }); I posted this to github as well...

The polyfill dude is lacking free time to complete his work. Do help with the issues, if you want to see it progress.

Glad to hear that ! Now the "save the page and go to the frontend" button is not necessary anymore if you use PW3, because this functionality is integrated in the core.

Replacing the php tag with the one containing the namespace isn't the solution. Modules without namespace declarations should also function in PW3.x. At the moment I'm working on a new version supporting PW3.x. I guess I'll finish that this week (the next release will provide further improvements as well).

The message looks like the "created" column has a wrong default value, so the create statement for the published column probably triggered the error but isn't its cause. Open the schema for the pages table in phpMyAdmin and have a look there. The default value for "created" should be a date in 'YYYY-MM-DD HH:MM:SS' notation, if it's not, enter something halfway reasonable there (it shouldn't really matter which date though as PW will overwrite it), then try to execute the statements from SystemUpdate12.php again.

I added an option to disable multi-language fields. In field settings for Image Extra Fields there is a new checkbox "Disable multi-language fields?". Please pull branch develop to get this new feature. btw: branch develop is ProcessWire 3.x ready but it needs a bit more testing before I'll create a new release.

I'm getting a strange double vertical scrollbar. Chrome, Win7, 1600x900 <edit>The scrollbar in the image is the extra one, the 'normal' one wasn't in the screencap.</edit>

Did you save?

$t->flags = Template::flagSystemOverride; $t->flags = 0; // etc... save here or delete $t->save();

I kind of had this problem, and solve it using a "NOT" selector when retrieving the array. https://processwire.com/talk/topic/12798-remove-multiple-items-from-pagearray/ Though I know this is not exactly what you are asking since it's not dealing exactly with the array, but thought it could help.

@Ivan: A good idea. In fact, the one I initially had in mind, but I somehow got it into my head to save the settings directly with the template configuration which I couldn't. Of course, one thing doesn't necessitate the other and I can both hook into ProcessTemplate and use my own database table. So, version 0.0.6 is on GitHub and does allow that.

And to keep the copy pasting errors to a minimum: http://codepen.io/LostKobrakai/full/xVgooN/

The import methods does not search for pages. It does import either WireArrays of WireData objects (like Pages) or a simple php array of WireData objects. So it's not so important how those objects are group but the objects must be of the right type when importing.

Thanks for pointing me in the right direction Ryan. Although it took a bit of figuring tinkering around since I initially got this error "Field must be in fieldgroup context before its context can be saved" for those passing through this thread, finally got the following code working correctly: //add the field to the template first $mytemplate = wire('templates')->get('mytemplate'); $mytemplate->fieldgroup-add('roles'); $mytemplate->fieldgroup->save(); //-- we now *override* the default label and description to suit our template --// $field = $mytemplate->fieldgroup->getField('roles', true); //!IMPORTANT: set 2nd parameter to true to get the field in the context of the fieldgroup. //note: I don't really understand what "in the context of.." means though $field->label = 'Select roles'; $field->description = 'Select the roles that should receive notifications.'; //now save! wire('fields')->saveFieldgroupContext($field, $template->fieldgroup); For those who want to go through core, the hints are in wire/modules/Process/ProcessField/ProcessField.module

Try this: $title = $ls_fieldgroup->get('title', true); $title->collapsed = Inputfield::collapsedHidden; wire('fields')->saveFieldgroupContext($title, $ls_fieldgroup); I could probably make this simpler from the API perspective (to work more like your code example), but only you and I have needed this capability so far.

Think of ProcessWire's tree like a fractal. There is no difference between multiple trees, and branches within a tree. Both can extend forever in the same way. ProcessWire knows nothing about menus. So what is or isn't a menu is based entirely on what you make it, there are no limits. You can have as many menus, whether structured, or flat (via page references, toggles, etc) as you want. Here are common ways of drawing upon ProcessWire pages for menus, but these are just examples in unlimited possibilities: It's common to relate your first level of pages to your top navigation: $topnav = $pages->get('/')->children; It's also common to relate the children of your first level as secondary navigation (which you might also carry further into the structure for tertiary navigation and more): $subnav = $page->rootParent->children; If you wanted dynamic footer pages, you might create a structure where they will be (whether actual viewable pages or redirects): $footerNav = $pages->get('/tools/footer-nav/')->children; Or you might assign footer links via a multi-page reference field on your homepage template, where you edit your homepage, pluck out the pages you want to appear in your footer (using a PageListSelectMultiple input) and drag to order them. (this would be my preferred option) $footerNav = $pages->get('/')->footer_nav; Or you might just put a checkbox field on every page that says "show in footer", and check the box for the pages you want in the footer. $footerNav = $pages->find("footer_nav=1"); Or you might use a repeater to create a more literal menu with title (anchor text) and the URL it should go to. This is just for starters. Pull away from the rigid thinking of other CMSs and you'll find anything is possible.