Leaderboard

Continuing from the Repeaters thread about the field-template context… This video demonstrates how you can adjust the admin context of individual fields according to the template they are placed in. When you adjust the context in this manner, it only changes the settings for when a field appears in that template. This expands the reusability potential of fields across different templates, hopefully preventing the need to create another field if all you really needed was a different title, description or width. You can do this same type of configuration when editing a field in a repeater too. View this full screen which should put YouTube into HD mode, where it's much easier to see.

Perfect! This really puts PW ahead of anything I've seen in all aspects, not only in development flexibility...

Here's my first draft for the Spanish translation. Please note that: It's fairly complete, but not quite ready for production. Spanish is not my mother tongue (I'm French), but I've been living in Spain for 10 years so it should be acceptable. Contributions and suggestions are welcome. I will post updates as necessary. This is Spanish for Spain. Some parts of the translations might not be appropriate in South American countries for example. In particular, I've used the less formal, more direct version of "you": "tú" as opposed to "usted", which is much more common in Spain. I love ProcessWire and I'm glad I can contribute to this awesome project. UPDATES: December 10, 2013: Translation files updated for dev version 2.3.8 (see "spanish-spain-december2013.zip" below) March 4, 2014: I've created a Github repository that I plan to update whenever possible. All updates will be posted there from now on. June 16, 2014. Update to 2.4.4. spanish-spain.zip spanish-spain-december2013.zip

OH. MY. GOD. Tell me I'm not dreaming! I've been scouring the Internet for weeks looking for a CMS that would allow me to give my clients a decent user experience. I've developed sites in Joomla, Drupal, Silverstripe, and Wordpress. Joomla was a nightmare of epic proportions. The admin interface is confusing and inconsistent. Drupal had promise in theory, but trying to customize it just caused it to bug out. Silverstripe is nice, but the admin panel is slow and clunky. Wordpress is great for blogs, but feels like you're hacking it if you're trying to use it for more than that. After my frustrations with the big name CMSs, I decided to try and get a better lay of the land and see what else was out there. Every one of them was either lacking a crucial feature, poor on the usability front, or a buggy mess. I have some programming knowledge, but mainly I am a designer looking for a CMS that lets me design the client's experience in the same way that I'm able to design the end user's experience. I don't need templates or templating languages. I want something that lets me be the designer and then gives my clients the power to work with what I've developed. As someone deeply concerned about user experience, I don't understand it. How could so many developers get this so wrong? Were they just throwing these things together without thinking about the use cases? The need for flexibility? What people actually NEED in a CMS? I was beginning to think I'd have to become a PHP developer and build something from scratch. So far, what I see in ProcessWire is almost exactly the ideal CMS I have been piecing together in my mind's eye. The consistency in the mental design model, the absolutely crucial ability to create your own page types and custom fields for your clients which is utterly lacking or nonexistant in nearly every major CMS, the ability for logged in users to easily update a page they're on by simply hitting an "edit" link from the front end... Elegant, logical, and flexible. It's obvious that you've put a lot of thought into this. Thank you. I can't wait to get started.

My jaw is somewhere near the floor after that video ryan - that's amazing! Not only due to the fact that you can give names and descriptions (amongst other things) for fields on a per-template basis, but also seeing a very good usage scenario for the resized field widths! I hadn't thought of anything as useful as that yet but can definitely see quite a few templates where that sort of layout is going to work so I'm going to start playing with them right now to vastly improve my templates

Um... wow!!! This just made my day! Thanks for the video Ryan. I'm so impressed with the speed of development on ProcessWire. Field contexts should be a UX designers dream. Of all the features lately this is definitely my favourite - so powerful when combined with repeating fields. I have struggled for so long with other CMS's to get the admin interface to become usable and friendly for clients - this is a massive step forward for me - as constantly creating new fields for various templates just to change a field title was a tad cumbersome. I really like the modal windows to set the new field contexts along with the width settings - so useful.

No, you're not dreaming, but it's like a dream!

Thanks for posting Soma, this is an interesting approach and not one I've seen before, but it looks great. The underlying concept and result is similar to the approach I usually use. Since you posted a good description, I'll try to do the same for mine. The only reason you see head/foot files in the default PW profile is because it seems to be simpler for new users to grasp. But I almost never use that approach in my own sites. Like your system, I have a main.php file which is my main markup file. But unlike your system, main.php is included from all the other template files (rather than main.php including them). The other template files focus on populating the key content areas of the site, specific to the needs of the template. Examples of key content areas might include "main" (for center column/bodycopy) and "side" (for sidebar/related info), though often includes several other identified areas. But I'll keep it simple in this case. Here's how it works: basic-page.php <?php $outMain = "<h2>{$page->subtitle}</h2>" . $page->body; if($page->numChildren) $outMain .= $page->children->render(); // list the children $outSide = $page->sidebar; include("./main.php"); main.php <html> <head> <title><?php echo $page->title; ?></title> </head> <body> <h1><?php echo $page->title; ?></h1> <div id='main'><?php echo $outMain; ?></div> <div id='side'><?php echo $outSide; ?></div> </body> </html> The benefit of this approach is that basic-page.php can setup whatever it wants in the key content areas ($main or $side) whether simple like in this example, or something much more complex. I actually prefer for the variables representing the key content areas to be optional. In the scenario above, $outMain and $outSide would have to be defined by every template or they would end up as uninitialized variables in main.php. As a result, I actually use $page as an anonymous placeholder for these variables (making sure they don't conflict with any existing field names) and then let main.php assign defaults if the calling template didn't specify one of them. For example: basic-page.php <?php $page->outMain = "<h2>{$page->subtitle}</h2>" . $page->body; if($page->numChildren) $page->outMain .= $page->children->render(); // list the children // note: no $outSide specified include("./main.php"); main.php <?php // setup defaults when none specified if(empty($page->outMain)) $page->outMain = $page->body; if(empty($page->outSide)) $page->outSide = $page->sidebar; ?> <html> <head> <title><?php echo $page->title; ?></title> </head> <body> <h1><?php echo $page->title; ?></h1> <div id='main'><?php echo $page->outMain; ?></div> <div id='side'><?php echo $page->outSide; ?></div> </body> </html> Final thing to point out here is that main.php is the only template actually outputting anything. Because basic-page.php (or any other template) is determining what's going to go in that output before it is actually sent, your template has the opportunity to modify stuff that you might not be able to with other methods. For instance, the <title> tag, what scripts and stylesheets are loaded, etc. Here's the example above carried further to demonstrate it: basic-page.php <?php // make a custom <title> tag $page->browserTitle = $page->rootParent->title . ": " . $page->title; $page->outMain = "<h2>{$page->subtitle}</h2>" . $page->body; if(count($page->images)) { // display a clickable lightbox gallery if this page has images on it $config->scripts->add($config->urls->templates . "scripts/lightbox.js"); $config->styles->add($config->urls->templates . "styles/gallery.css"); $page->outMain .= "<ul id='gallery'>"; foreach($page->images as $i) { $t = $i->size(100,100); $page->outMain .= "<li><a href='{$i->url}'><img src='{$t->url}' alt='{$t->description}' /></a></li>"; } $page->outMain .= "</ul>"; // add a note to $page->title to say how many photos are in the gallery $page->title .= " (with " . count($page->images) . " photos!)"; } if($page->numChildren) $page->outMain .= $page->children->render(); // list the children include("./main.php"); main.php <?php // if current template has it's own custom CSS file, then include it $file = "styles/{$page->template}.css"; if(is_file($config->paths->templates . $file)) $config->styles->add($config->urls->templates . $file); // if current template has it's own custom JS file, then include it $file = "scripts/{$page->template}.js"; if(is_file($config->paths->templates . $file)) $config->scripts->add($config->urls->templates . $file); ?> <html> <head> <title><?php echo $page->get('browserTitle|title'); // use browserTitle if there, otherwise title ?></title> <?php foreach($config->styles as $url) echo "<link rel='stylesheet' type='text/css' href='$url' />"; foreach($config->scripts as $url) echo "<script type='text/javascript' src='$url'></script>"; ?> </head> <body> <h1><?php echo $page->title; ?></h1> <div id='main'><?php echo $page->get('outMain|body'); // use outMain if there, or body otherwise ?></div> <div id='side'><?php echo $page->get('outSide|sidebar'); // use outSide if there, or sidebar otherwise ?></div> </body> </html> More than half the time, I'll actually just re-use page variables like $page->body and $page->sidebar rather than $page->outMain and $page->outSide. That way there's no need to consider defaults, since $page->body and $page->sidebar untouched technically are defaults. <?php $page->body = "<h2>{$page->subtitle}</h2>" . $page->body . $page->children->render(); But technically you've got a little more flexibility using your own self-assign anonymous variables like outMain and outSide, so figured I'd use that in the examples above. outMain and outSide are just example names I came up with for this example and you could of course name them whatever you want.