Leaderboard

So, I figured it was time to post an update to this great thread. Thanks to the truly exceptional help from Bernhard, and from others including kixe, OrganizedFellow, Peter, and cstevensjr, I am on my feet with this. while I didn't exactly follow the summary that Bernhard posted in the immediately previous message, it was close enough. The site is loaded and functional! This has allowed me to begin exploring the inner workings of the site - expect me back at any time without notice! Thanks again, guys. It was great help.

In slick, if you set "autoplaySpeed" to something quite low (10 or so) and "speed" to something quite high (10000 or higher) you should get a nice result. See http://codepen.io/anon/pen/WQJPXr

You could also accomplish this with pure CSS. Lets say your CKEditor content gets ouput in your template inside a <div class="maincontent">CKEditor content with <img> tags</div> If you are using SASS version of Bootstrap, in your scss you can do .maincontent img { @extend .img-responsive } If you are using plain CSS (taken from the img-responsive class) .maincontent img { display: block; max-width: 100%; height: auto; }

I am converting a Joomla/Seblod install and in that process developed a widget system quite similar to Marcrura's. In Joomla widgets are called modules and in that particular install those modules were used quite a lot. To render modules (widgets) in Joomla you do something like <?php if ($this->countModules('content_bottom')): ?> <div class="content_bottom"> <jdoc:include type="modules" name="content_bottom" style="inner" /> </div> <?php endif; ?> So I tried to find a way in PW to conditionally output widgets. In my widget template, I have widget positions and layouts as page fields, just like Marcrura shows. Plus a page field of type PageListSelectMultiple to determine on which pages to show the widget. And, like Berhard, I have a checkbox to determine whether to show the widget also on child pages. Instead of using includes for each widget position, I use switch case statements in my widget template // get layout $layout = $page->layout->name; // layouts switch ($layout) { case 'carousel': // code to render carousel markup echo $carousel; break; case 'teaser': // code to render teaser markup echo $teaser; break; // ... etc. I use the delegate template approach like in the default site template with an _init.php that gets prepended and a _main.php that gets appended and outputs variables that are being populated in the page templates. Here is the logic to render widgets in the main content area of my _main.php <main class="col-sm-<?php echo $contentwidth; ?> content equalHeight"> <?php if($above) { ?> <!-- widget position above --> <div class="above"> <?php echo $above; ?> </div> <?php } ?> <?php echo $content; ?> <?php if($below) { ?> <!-- widget position below --> <div class="row below"> <?php echo $below; ?> </div> <?php } ?> </main> $above and $below hold the markup for all widgets in that position on that page and are false if there are none. And this is the code I use to determine whether there are widgets in that particular position on that particular page. In my _init.php I first set all position variables ($above, $below etc.) to false. (module translates to widget here) // Set all module variables to false foreach ($pages->find('template=modulepositions_items') as $position) { ${$position->name} = false; } The widget position pages all have the template modulepositions_items. So I iterate through all positions and then use Variable variables to create the position variables ($above, $below etc.) and set them to false. This step is needed to avoid PHP "Undefined Variable" notices. In my _main.php I store the widget markup in the position variables before all the other template markup (again module translates to widget) // get modules $modules = $pages->find('template=module, sort=sort'); // render modules in their positions foreach ($modules as $module) { // if module is assigned to this page or it's parent, render it on it's position if (count($module->onpages) == 0) { // if no specific pages are assigned, render module on all pages ${$module->moduleposition->name} .= $module->render(); } elseif ($module->include_children == 1 ) { if ($module->onpages->has($page) || $module->onpages->has($page->parent('id!=1'))) ${$module->moduleposition->name} .= $module->render(); } elseif ($module->include_children == 0 && $module->onpages->has($page)) { ${$module->moduleposition->name} .= $module->render(); } } Lets brake this down: "onpages" is the page field in my widget template that determines on which pages to show the widget. ${$module->moduleposition->name} .= $module->render(); renders the markup $module->render() of the widget and adds it to the position variable ${$module->moduleposition->name} which again is a variable variable (just like that expression too much ) The if and elseif statements check whether the widget should be rendered on that particular page. They feel a bit clumsy and I think I will change my setup to using the selector field instead. To summarize: with this method you get a quite flexible widget system with the benefit of minimizing the code used to render them in _main.php and the possibility to have conditional markup depending on whether there are widgets for that position or not. Thank you guys for sharing your approaches which gives me some good ideas for improving on my own.

Hey, Been using this starter theme for a little while now and thought I'd open it up on github - https://github.com/benbyford/bb-starter It has all my favourite modules installed, .less, some hany .js libraries and a set of blog templates for a simple news / blog setup. The theme is built on the simple theme from PW with additional setup. For more info see the Readme.md file on github. See it here - http://bbstarter.nicegrp.com/ Thanks everyone for your continued work and fun using PW.

AvbImage - Image Manipulator Module for ProcessWire This module using Intervention Image PHP image handling and manipulation library. Update Status Module and InterventionImage Library update - 10-12-2015 More performance imporements - 18-11-2015 Module Update and Performance Improvements - 17-11-2015 First Commit - 28-10-2015 RequirementsProcessWire >= 2.5.11 PHP >=5.4 Fileinfo Extension Supported Image LibrariesGD Library (>=2.0) Imagick PHP extension (>=6.5.7) For usage and methods please look githup repo : README.md > For issues and fix and corrections please use Githup Repo

https://processwire.com/talk/topic/11069-sorting-images-in-backend/?fromsearch=1

Hello, I would like to utilize wire/modules/Inputfield/InputfieldIcon/ in a module. I found that icons.inc there does not include all FontAwesome 4.4 icon classes. Is the selection of icon classes in icons.inc opinionated for use in PW or is it just not up to date? Anyways, I put together some code to produce a icons.inc with all available FA icon classes from master branch, sorted alphabetically: <?php $url = "https://raw.githubusercontent.com/FortAwesome/Font-Awesome/master/src/icons.yml"; $faArray = yaml_parse_url($url); // pack all icon ids (classnames) in array and sort alphabetically $iconClasses = []; foreach ($faArray['icons'] as $key => $row) { $iconClasses[$key] = $row['id']; } array_multisort($iconClasses, SORT_ASC, $faArray['icons']); // write all fa classnames to a file $file = "icons.inc"; $prefix = "fa-"; $out = fopen($file, "w+"); foreach ($iconClasses as $c) { $class = $prefix . $c . PHP_EOL; // echo $class . "<br>"; fwrite($out, $class); } fclose($out);

Awhile back, I made an Ajax API for querying pages in the admin via the ProcessPageSearch module. It is used by [for example] the PageAutocomplete Inputfield. I thought this capability would be useful on the front-end too, so this module brings it to the front-end as a page in your site that you can put wherever you want to. The way you use it is exactly the same as the one in ProcessPageSearch, but this one is a little more strict, given that it's publicly available on the front-end. By "more strict" I mean that you have to define what you want to allow in terms of input and output in the module's configuration. The web service takes it's query from GET variables in the URL and returns results in JSON format. It installs a page called /service-pages/ in your site, and you are welcome to move that page wherever you want. Here is the official page at modules.processwire.com: http://modules.processwire.com/modules/service-pages/ Once installed, you should view the /service-pages/ page that it installs because it outputs detailed instructions and examples on how to use it in your own projects. But here's a few excerpts from what you'll find on that instructions page: Input The /service-pages/ page can be queried with GET variables in the URL to return JSON-format results. The query string should follow a ProcessWire selector format ([field][operator][value]), but modified a bit for use in a URL query string. Here are a few format examples: Specify a single value: ?field=value Specify multiple fields and values to match: ?field1=value1&field2=value2&field3=value3 Specify multiple fields where at least one must match the value. Note use of "," rather than "|", something we had to settle for to make it work as a URL key: ?field1,field2,field3=value Specify one field with multiple possible values (it's fine to use "|" as a separator here): ?field=value1|value2|value3 Note that unlike regular ProcessWire selectors, multiple field=value sets are split with an ampersand "&" rather than a comma ",". Allowed Values The allowed values for field are set with the module configuration. You may also specify the following modifier keyword=value pairs: sort=[field] (Specify field name to sort results by) debug=1 (Enables debug mode producing human readable output) limit=[n] (Specify the max number of pages to return) start=[n] (Specify the result number to start with) include=hidden (Include pages that are 'hidden') Allowed operators The operator demonstrated by the "=" sign in the examples above may be replaced with any of the following operators in the query string: = Equal to != Not equal to < Less than > Greater than <= Less than or equal to >= Greater than or equal to *= Contains the exact word or phrase ~= Contains all the words %= Contains the exact word or phrase (using slower SQL LIKE) ^= Contains the exact word or phrase at the beginning of the field $= Contains the exact word or phrase at the end of the field As an example, this ProcessWire selector: template=property, body*=luxury, bedrooms>5, bathrooms<=3 ...would be specified as a query string to this web service like this: ?template=property&body*=luxury&bedrooms>5&bathrooms<=3 Allowed templates For security, the search will only be performed on pages using templates that are defined in the module's configuration. Output The returned value is a JSON format string in the following format (populated with example values): { selector: "title*=something, template=basic-page, limit=50", total: 2, limit: 50, start: 0, matches: [ { id: 1002, parent_id: 4525, template: "basic-page", path: "/test/hello/", name: "hello" }, { id: 1005, parent_id: 4525, template: "basic-page", path: "/test/contact/", name: "Contact Us" } ] } Each of the 'matches' values will also include all the fields you have specified to appear with the ServicePages module configuration. If an error in the query prevented it from being performed, a JSON string in this format will be returned: { errors: [ "Error message 1", "Error message 2 (if there was one)", "And so on..." ] } The web service honors user view permissions. As a result, if you are accessing this service from a superuser account, you are likely to get pages that others users may not see. Superusers get an "include=all" automatically, unless you override it with an "include=hidden". Returned field values The following field values will be returned for all matched pages: id (integer) parent_id (integer) template (string) path (string) name (string) Any other fields may be included from the module's configuration screen. Pagination To paginate, simplify add a "page[n]" url segment to the request URL, i.e. /service-pages/page2/?template=basic-page&sort=name

Some sites need widgets, as they have been called in some systems; a widget can be almost anything, like: tag cloud mini calendar menu quote rotator free text social sharing search contact info map This is a simple way to create widgets that can be shown in multiple "areas" of a page, as well as on specific pages. In this particular method you would need to setup each widget type you want and then determine how best to accept any necessary user input like content, pages select (like for a menu) or settings. This example uses include files for each widget type, and the name of the include file would match the name of the widget type, which is also a page field. In this example, I'm also using ListerPro to provide a widget management page. Fields The main fields used on this widget example are : title widget_location (page select - options in this case are footer and sidebar) widget_type (page select, you would configure your widget types as selectable options) pages_select (would be used for multiple pages and might apply to a menu widget) body - used for plain widgets selector (selector inputfield, used for telling the system where to show the widget) text_structured - for this i'm using a YAML field, but it could just as easily be a table; would depend on what you want to store; YAML would allow this single field to be used for varying requirements based on the widget type, but would be harder to validate and prone to user error; icon - a page select for an optional icon which is being used in the template, and would be shown as part of the widget. Files for each widget type you want to allow users to select from, you would need to create an include file with the markup for that widget, and then add that widget to the list of available widgets. here is an example for a site with several widget types: Selector & Output wherever you want to include the widgets (footer, sidebar etc.) you would run a $pages->find and then foreach through the widgets (in this case finding all footer widgets). In this case the (incredibly amazing new) selector field would be specifying what pages to show the widget on. We assume that most widgets won't have a selector specified, and will default to show the widget. if a selector is specified, we can check to see if this page fits the selector by using the $page->is($selector) syntax. <?php $widgets = $pages->find("template=widget, widget_location=footer, sort=sort"); foreach($widgets as $widget) { // check if the selector field is in use and if so, see if this page is supposed to display it: if( $widget->selector) { if( !$page->is("$widget->selector") ) continue; } $widgetType = $widget->widget_type->name; $include = file_exists("./inc/widget-{$widgetType}-foot.inc") ? "./inc/widget-{$widgetType}-foot.inc" : './inc/widget-footer.inc'; include($include); } ?> this example also has a fallback file in case the widget type is not specified, sort of a default. the widget's .inc file will be unique to your design and how you have it setup.

WireMailBranding Add email templates to wireMail From this: $mail->bodyHTML("<h1>Hello</h1><p>I'm WireMailBranding</p>"); To this: (or whatever template you create) How it works? Create an email template without content. On the spot where you wish to have your content place the tag {bodyHTML}.The markup you've set with $mail->bodyHTML('<p>Markup</p>'); will replace that tag. You could set the defaults in the Module configuration or set the properties with the API. (See below) The API will overwrite the default settings $mail = wireMail(); $mail->to('user@some-domain.ext')->from('you@own-domain.ext'); $mail->subject('Mail Subject'); // Set path to template (overwrites default settings) $mail->template('/site/templates/template_wrapper.php'); // Enable/Overwrite the Emogrifier CSS inliner. (0, bodyHTML, wrapper) $mail->inlineCSS('bodyHTML'); $mail->bodyHTML('<p>This paragraph will replace the {bodyHTML} tag in the mail template.</p>'); $mail->send(); CSS inliner We have added the beautiful css inliner Emogrifier to inline the CSS styles. When using the Emogrifier CSS inliner applying it on the bodyHTML only is the most efficient way. We recommend you to write the inline styles for the wrapper manually. The module is sponsored by Calago.nl. Thanks guys ! Updates 0.1.2 Bug fixes : - Fixed redeclare Emogrifier bug. Improvement - Added error logging for Emogrifier - Added inputfield error for the lack of PHP's mbstring in the module configuration. - Some code cleaning and other cosmetics 0.1.3 Bug fixes : - Fixed bug when module couldn't grab bodyHTML (resulted in doing nothing at all). GitHub https://github.com/Da-Fecto/WireMailBranding Modules directory http://modules.processwire.com/modules/wire-mail-branding/

Adrian was just quicker... we probably need more code to help if that snippet doesn't work. Anyways, I always have a good laugh when reading about those dam(n) pages and templates

Just change the last line to use another field: $form->insertBefore($button, $form->get("id"));

I found this http://stackshare.io/processwire we should give processwire more likes and up votes

Sure this is another dependency. Using LESS/SASS you will always need some dependencies like preprocessors. But with package managers like bower etc. organizing dependencies is a breeze. And this can be used with any template approach, be it the delayed output strategy or not. What makes using LESS/SASS a big timesaver for me is that writing the CSS code becomes much faster. Also separating your CSS into chunks (partials) improves maintainability a lot.

I was looking into cross browser save flexbox grid frameworks myself the last days and found http://leejordan.github.io/reflex/docs/. Haven't tried it yet, though. But might be worth taking a closer look.

I'm using good old "compass watch" in the terminal from within my template folder to compile my SASS/SCSS. So I don't need any other tools than compass. A typical site/templates/config.rb (taken from my https://github.com/gebeer/site-pwbs profile) for compass looks like: require 'compass/import-once/activate' # Require any additional compass plugins here. add_import_path "bower_components/bootstrap-sass-official/assets/stylesheets" # Set this to the root of your project when deployed: http_path = "/" css_dir = "css" sass_dir = "sass" images_dir = "images" javascripts_dir = "js" # You can select your preferred output style here (can be overridden via the command line): # output_style = :expanded or :nested or :compact or :compressed

ProcessWire doesn't work without an .htaccess file in the root folder.

It's actually quite simple once you get the hang of it. For one, it's far less scripting in coparison to Grunt/Gulp. Right now, my NPM config for my own site in development is this: { "name": "FoundryAssetsPackage", "preferGlobal": true, "private": true, "devDependencies": { "rimraf": "latest", "mkdirp": "latest", "less": "latest", "uglifyjs": "latest", "watch-cli": "latest", "jshint": "latest" }, "scripts": { "clean": "rimraf build/* && mkdirp build/ecma build/css", "prebuild": "npm run clean", "less": "lessc --clean-css src/less/main.less build/css/main.css", "ecma:lint": "jshint src/ecma/site.js", "ecma:packages": "uglifyjs src/ecma/packages.js -o build/ecma/packages.min.js -cm --comments", "ecma:site": "uglifyjs src/ecma/site.js -o build/ecma/site.min.js -cm --comments", "tasks": "npm run less && npm run ecma:packages && npm run ecma:site", "build": "npm run tasks", "watch:less": "watch \"-p src/less/**\" -c \"npm run less\"", "watch:ecma": "watch \"-p src/ecma/**\" -c \"npm run ecma:packages && npm run ecma:site\"", "watch:all": "watch \"-p src/**\" -c \"npm run build\"", "all": "npm run build && npm run watch:all" } } As soon as you understand how to use a terminal, understanding the above is quite simple.

hi again, Thx for your detailed reply! I tried the zip upload, it also does not work 100%. Uploading a 40MB Zip File works, but everything over about 150MB failes, i have 250 MB max_filesize and 250 memory_limit, maybe that's not enough and the error i get doesn't help => Uncaught TypeError: Cannot read property 'error' of null(anonymous function) @ InputfieldFile.min.js?v=118:1 I bulid workaround upload page where i upload the zip, unpack it and add the images via API.

You can also do a var_dump($event); die(); in the module to see its content or use $event->return or $event->arguments if $event alone does not work

https://github.com/ryancramerdesign/ProcessWire/releases/tag/2.3.0

https://github.com/ryancramerdesign/ProcessWire/releases

If it's template files you want to edit directly within the Admin, there is a Module available http://modules.processwire.com/modules/template-editor/

First: were you able to get a clean install running? Do that. Get your permissions set up http://processwire.com/docs/security/file-permissions/ Also there is a different setup if your Apache is version older than 2.4. It's commented in the $root/.htaccess file. Checkout lines 52-75. It explains there. I'm sure we can all help you get this up and running soon! hang in there

Put this in one of your templates, <?php echo $config->version; ?>

I haven't yet had a chance to play around with ProcessRedirects on multi-language sites, and so can't be sure why that is happening. Have you perhaps tried using Jumplinks?

@horst That sounds definitely clumpsy. What about some buttons in the page editor? Put this as is in /site/ready.php: $wire->addHookAfter("ProcessPageEdit::buildForm", function(HookEvent $event){ $process = $event->object; $form = $event->return; $page = $process->getPage(); // Update to fit your fieldnames $imageFields = array("images"); $multiple = $page->fields->find("name=" . implode($imageFields))->count() > 1; foreach ($imageFields as $field) { if($page->fields->has($field) && $page->editable($field)){ if(wire('input')->post("hook_sort_$field")){ $page->of(false); $page->set($field, $page->get($field)->sort("basename")); $page->save($field); } $button = wire('modules')->get("InputfieldSubmit"); $button->attr("id+name", "hook_sort_$field"); $button->value = __("Bilder Sortieren"); $button->value .= ($multiple ? " (" . $field->get("label|name") . ")" : ""); $button->icon = "sort-alpha-asc"; $button->addClass("ui-priority-secondary"); $form->insertBefore($button, $form->get("id")); } } });

I'm pretty close to having native core support for multi-language page names. It's something I wanted to add originally in 2.1, but just didn't know exactly how without adding lots of overhead. After marinating on it for a long time, an easy way to accomplish it finally became apparent. A nice thing about it is that it does it with near zero overhead. It won't be as fancy as the LanguageLocalizedURL module, but it should be good for people that have relatively simple needs. It's the one feature that we were missing that would really let the multi-language fields sing, and it should lead the way for making more fieldtypes multi-language capable. It works by enabling you to specify an alternate name for each page, for each language. When a page is accessed at its alternate URL, then the language is automatically detected and set for the request. Combined with multi-language fields or multi-language alternate fields, it provides a full multi-language solution without need for multiple trees or having to use any code to set the language. It's not the right solution for all situations, but for some situations, it'll be quite nice. Lets say you've got the page /about-us/contact/. For the "about-us" page you've set the Spanish language name to be "quienes-somos", and for the "contact" page you've set the Spanish language name to be "contacto". When the URL /quienes-somos/contacto/ is accessed, it's technically referring to the same page as /about-us/contact/, except that the user's language is automatically set to Spanish, and thus any multi-language fields output in Spanish. Calls to $page->url on any other pages also output the Spanish URLs. You don't have to define alternate labels for all pages if you don't want to. So long as there is just one of them in the URL (like in the rootParent, for example) then it'll be able to detect the language automatically. In order to avoid problems with having multiple URLs displaying the same content, it doesn't let you access the page with a URL like /about-us/contacto/ (English and Spanish mashup), because both of those pages have their names translated. So if you accessed such a URL, it would 301 redirect to the Spanish version. Here's a screenshot that might help to explain how these things are defined. This will be committed to the core within the next few days, as part of the LanguageSupport group of modules, but I'm going to leave it as an uninstalled alpha then beta module, until ProcessWire 2.4.

it was, but made some problems and other parts were more important. you are right, i think a search would totally make sense and maybe we will ad it one day. thanks for the input! thank you! i changed it to SVG but it's not better. i think that's the fault of the logo itself because in my editor it also does not look very nice? do you see any difference? thank you i'm using pagetable instead of repeaters now because the UI is much clearer and they do not waste so much space. did a little screencast for some more insights - also on the edit-shortcut-links

Hmm... When I try this with templates I get the error "You must save Fieldgroup 'X' before adding to Template 'X'" It seems like that would be the job of the setImportData() function to make sure that happens? Edit: Got it. Here's the template builder: protected function buildTemplatesFromJson($json) { $data = is_array($json) ? $json : wireDecodeJSON($json); // Loop through each template in the JSON foreach($data as $name => $templateData) { unset($templateData['id']); // Get rid of the ID so it doesn't conflict with the new installation $template = $this->templates->get($name); // If the template exists, grab it // Create the template if it doesn't already exist if(!$template) { $template = new Template(); $template->name = $name; } $template->setImportData($templateData); // Import the data for the field $fieldgroup = $template->fieldgroup; $fieldgroup->save(); $fieldgroup->saveContext(); $template->save(); if(!$template->fieldgroup_id) { $template->setFieldgroup($fieldgroup); $template->save(); } } }

Okay, so after playing around with this and looking at Ryan's code in ProcessFieldExportImport I was able to put together a simplified function to create fields from a JSON export. This only creates a field if it doesn't already exist, and you can do it one at a time or send in multiple fields at once. protected function buildFieldsFromJson($json) { $data = is_array($json) ? $json : wireDecodeJSON($json); // Loop through each field in the JSON foreach($data as $name => $fieldData) { unset($fieldData['id']); // Get rid of the ID so it doesn't conflict with the new installation // Create the field only if it doesn't already exist if(!$this->fields->get($name)) { $field = new Field(); $field->name = $name; $field->setImportData($fieldData); // Import the data for the field $field->save(); } } } Calling it from within my module's install() function: $this->buildFieldsFromJson('PASTE_JSON_EXPORT_HERE'); Hope that helps someone else. Now onto the templates...

great writeup macrura! what do you mean by the incredibly amazing new selector field? edit: oh - just saw what you meant on your screenshot and didn't see it before!!! i thought you were talking about the page select field... where can i find more info on this? -------------------------------------- here is my old posting - just for the record. it seems it is quite useless having the new selector field edit: polished version here: https://processwire.com/talk/topic/8635-simple-example-for-widget-management/?p=95532 i also have a widget setup on one of my sites with a little different approach of how to manage visibility of the widgets (3rd column: if this box is checked, the rule applies also to its sub-pages) for every widget you can setup "display rules" including #page #include/exclude and #include_children. it's kind of a bottom-up approach: the example above would show the widget on all subpages of /games AND on page /games (rule #3), but would NOT show an page /games (rule #2 removes access given from #3) and would not show an any other page (home + subpages, rule #1). a simpler example would be: rule | page | | sub-pages? ------------------------------------------ #1 | home | exclude | yes #2 | /section1 | include | yes so this widget would show on all pages in section1 (eg /section1, /section1/post-1, /section1/post-2 ...) you could easily exclude the widget on page /section1/post-2 by adding #3 | /section1/post-2 | exclude | no ...and it would still display an all other pages (posts) in section1, including newly added ones (post-3, post-4...). if anyone is interested in the code i can share it with you - altough it's quite messy because it's only a prototype for now. i also have to say that i don't like the repeaters because they are wasting lot of space for displaying only 3 small pieces of information. maybe a pagetable field would be better for the next version... i'm also managing this site on my own, so i have no experience with clients handling this display rules for now!

If you don't want a user deleting pages, then it should be as simple as not giving them page-delete permission. If you want to change the behavior on a per-template basis, then come up with two roles... one that has delete permission and another that doesn't. Give the user both roles. On templates where you want them to be able to delete pages, assign both roles. On templates where you don't want them to be able to delete, then only assign edit permission to the role without page-delete permission.

You can do it if using Inputfields from the API, but not from Setup > Fields > some_checkbox_field. Though I'm not sure what you mean about a double negative. ProcessWire is designed to be friendly to schema changes. We assume that you are probably not defining everything you need ahead of time. As a result, it's preferable to use a checked checkbox field to alter a default behavior, not to enforce one. Lets say you have hundreds of pages using some template, and you decide to add a new checkbox field called enable_nav that you use to determine whether or not to show navigation on a page. You could say that you wanted that checkbox to be checked by default... great, but that only applies to pages created from this point forward. All your existing pages didn't have the field before, and are not checked. So now you have a new problem. Now consider the the alternative, which would be to make your checkbox do the opposite. Instead of calling it enable_nav, you call it disable_nav. Add it to your template, and your existing pages are kept in the proper default state. New pages created from this point forward will check a box to bypass a default state rather than enable one. Using this strategy scales well, enforces consistency and don't break existing systems when you add a new field.

This is actually pretty interesting topic, started googling for more: http://blog.millerme...pre-processors/ Then there is this from 2009: http://nathanborror....0/sass-isnt-me/ and in comments Jeff Croft says: Forward few years and from Jeff's own blog (http://jeffcroft.com...eature-of-sass/):