Leaderboard

The field-template context is now committed to the source, so it is ready to use. Please let me know how it works for you guys. You can access it from any template or repeater field by clicking on a field name in the asmSelect list. When you first add a new field to an existing asmSelect, the context option isn't yet available. You have to save the template before you'll see the option to alter its context. When editing a field (from Setup > Fields), you will also see a context pulldown in the upper right corner. This is just a shortcut when/if you want it. -- Edit: you may need to hit 'reload' in your browser once or twice if you aren't seeing the field context option at first (old files may be stuck in cache).

(Added by Soma) Note that this module is deprecated. The newer and more maintained version is found here: https://github.com/somatonic/Multisite/ You can get the current dev version here https://github.com/somatonic/Multisite/tree/dev (Original Post) Just pushed simple multisite module to github: https://github.com/a...ultisite.module What this module does? It allows you to run multiple sites with different domains run from single install, using same database. While you can easily do "subsites" like www.domain.com/campaign/, this allows you to turn that into www.campaign.com. This is nice stuff, when you have multiple simple sites, that all belong to same organisation and same people maintain. How to use it? Just create page with name like www.campaigndomain.com under your homepage, then edit this module through modules menu and add same domain there. If your domain resolves to same place where your main domain, it should just work. Please notice that if you have editing rights, it allows you to browse the site from www.olddomain.com/www.campaigndomain.com/, but users with no editing rights are redirected to www.campaigndomain.com (this is because session cookie is otherwise lost). Any problems? Not any real problems, at least yet known. Of course think twice when deciding should the site have own install instead of this. There are few benefits, like getting data from other sites, one admin view for all sites etc... but it can easily get out of the hands: number of templates, fields etc.. It is harder to maintain for sure. Isn't there multisite support in core? Yes, kind of. It is very different from this. It allows you to run multiple pw-installations with shared core files (/wire/ folder). This is totally different: this is single pw-installation which has multiple sites running from different domains. This is basically just a wrapper with one config field for this little snippet Ryan posted here: http://processwire.c...ndpost__p__5578 (so most of the credit goes to Mr. Cramer here). What it also does is that it manipulates $page->path / url properties to have right subdomain value.

The GitHub repo was just renamed from P21 to ProcessWire. For those that are pulling from this repo, you'll need to update your remote origin. To do that, type this at the command prompt in your PW installation: git remote set-url origin git://github.com/ryancramerdesign/ProcessWire …or this (apparently required for older versions of Git): git remote rm origin git remote add origin git://github.com/ryancramerdesign/ProcessWire If you are using a graphical client for Git, then I'm sure it's just a matter of clicking to a 'remote origin' setting and replacing the P21 URL with: git://github.com/ryancramerdesign/ProcessWire Thanks to Robert Zelník for the instructions on how to do this.

I don't think so. Advantages are in how to keep code in large sites easily maintainable.

I think it would be great and make sense to have repositories of scripts and modules that are approved by the PW members to ensure they're quality modules. With launching the new PW website we're working on it will come.

This is also interesting: http://foundation.zurb.com/

I was thinking it would be good if it was something people could contribute to fairly easily. I'm sure that a lot of ProcessWire users here have accomplished a lot of really cool things inside of their templates using the API, and if there were a central place that they could then submit those for the benefit of others, that would save people having to re-invent the wheel or ask on the forums. Which leaves more time for Ryan and others to work on the core and various modules Some kind of basic gatekeeping/moderation would probably be necessary to ensure a minimum quality standard for the scripts.

I like how they implemented this on symphony (ya again, i know). On the downloads section of the site they have extensions and utilities. Utilities would be more or less this kind of snippets. http://symphony-cms.com/download/xslt-utilities/

I had an hour to investigate both and select one for a client project I'm working on. I picked HTML Kickstart. Twitter Bootstrap looked great, but also made me think I'd need a couple days to get up-to-speed with it all... making me wonder if it would save me time over starting from scratch (which is what I usually do). Whereas HTML Kickstart seemed more accessible to get going immediately and save me time. If I needed the responsive layout for this particular project, I might have chosen differently. I also look forward to using Twitter Bootstrap in more depth hopefully soon too. But HTML Kickstart seemed to me like it has the better balance that would motivate one to use a framework like this in the first place--a time saver in every respect. Quite impressive what Joshuag has done with this. I hope to have PW profiles for both at some point.

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.