Leaderboard

Ok. We just launched our new website today, of course now running on ProcessWire. A long journey with many iterations and somewhat experimental. Still a work in progress, as much as never finished. There's a lot of inter-linkage going on between content news, projects and competence pages. Modules worth mentioning: TextformatterAutoLinks Markup RSS Feed http://update.ch (IE < 9 not supported, sorry. Old Androids may experience strange things)

If you set your image field to allow a maximum of 1 image, then you can treat it as a single value. However, if you have it set for more than one image, it is automatically an array, even if there is only 1 image in it. If it is an array, you then have to tell it which image in the array you actually want - for instance using first - just like any other array in PHP. However, normally you would allow more than 1 because you want to loop through them, for a gallery, for instance. If you only want 1 image, I suggest you edit the field and set the max number of images to 1, just to save confusion.

The disadvantage of this solution is that it requires 4 DB queries. As long as there is only a small amount of data, this should be fine. How about this: $ids = array(439,417,456,402); $result = new PageArray(); $p = wire('pages')->find("template=xx, field_x=439|417|456|402"); foreach ($ids as $id) { $result->append($p->get("field_x=$id")); } Needs only one query

(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.

@adrian: I'll take a closer look at that tab issue soon. About the link dialog, I'm not really sure -- it's probably the same thing as with image dialog, that it should be replaced. Too bad, since these super-clean dialogs are part of what makes Trumbowyg such a pleasure to use The scope of Trumbowyg seems pretty limited for the time being and for an example I haven't yet found any 3rd party plugins for it (regarding paste buttons and "pretty" code formatting). I'll take a closer look ASAP and see if there's anything available, otherwise might have to cook something up myself. In the meantime I've added some basic config options to the module. Edit: tab issue should be gone now. Forced higher z-index value to fullscreen Trumbowyg editors.

@Manfred62: https://github.com/teppokoivula/InputfieldTrumbowyg. Just for testing, though, it's far from polished (mostly just a quick fork of InputfieldCKEditor with 90% of everything stripped off). What I'm not really sure about, should this become a "finished" module, is how the images should be handled? Trumbowygs default image tool is clean and pretty, but doesn't really make sense in ProcessWire, so I'm thinking that the image plugin from other RTE's should probably be ported here or something like that..

Image successfully shown! My problem is I didn't check the module so it's not shown on the module list. Such a dumb mistake Thanks Adrian!

Go to the Modules tab on the back-end (Admin). Select the Core Tab at the top. You should see the Lister Module listed.

Christian As a starting point, create a folder in /site/modules/ called something like MyAdminTheme Then copy all the files from /wire/modules/AdminTheme/AdminThemeDefault/ into your new folder Change the name of the file AdminThemeDefault.module to MyAdminTheme.module Edit the file so that the class now says: class MyAdminTheme extends AdminTheme implements Module, ConfigurableModule { public static function getModuleInfo() { return array( 'title' => 'Default Admin Theme', 'version' => 1, 'summary' => 'Minimal admin theme that supports all ProcessWire features.', 'autoload' => 'template=admin' ); } So, the name of the folder, the file name and the class name all match. You can change the title, version and summary to what you want. Now go to your sites admin and modules and install this new module. That is your starting point - you can now edit it to your heart's content. I THINK that is how I did it last time! Someone else might pick up anything I have missed!

I may be wrong, but I don't think that sub-sub-selectors are possible. You'd have to loop through your repeater pages and collect the products where the title matches.

Mandrill's details can be plugged into the config on this module really easily: http://modules.processwire.com/modules/wire-mail-swift-mailer/ Have it working like a charm on several websites already EDIT: Mandrill also has the benefit over PHP mail as you say in that if an email address bounces or the user marks an email as spam it will not try to send again and therefore protects your reputation. With a little work with a webhook (plenty of docs on their site) you could automatically notify the website owner via email of any bounced addresses or unhappy customers who've marked your email as spam which I'm sure they'll appreciate!

Yes here $config->maxPageNum = 999; It's set in wire/config.php but you would add it to your site/config.php

@JanRomero: It's really nice that you help, - but your example isn't correct, at least for fields with multiple images, what is the default. Your example only works if the image field is set to accept only _one_ image, and not _multiple_. With multiple imagesfield, you need to specify the image you want to use, e.g.: $page->images->first()->url $page->images->last()->url $page->images->eq(0)->url // is the first image $page->images->eq(1)->url // is the second image etc. have a look at: http://processwire.com/tutorials/quick-start/images/ http://processwire.com/api/fieldtypes/images/

Table Use this for tabular data, like rate tables or other things that you might typically represent in a spreadsheet. Use it for situations where you don't need the full-blown flexibility of repeaters, as it's technically more efficient with far less overhead than repeaters. Something like the Events Fieldtype could be very easily re-created via a Table field, but the potential uses are far broader. But for the most part, think tabular data when it comes to the Table field. Multipliers This is good for when you need a range of values (whether text, textarea, numbers, dates, etc.). If you are using repeaters with just one field in them, you might be a lot better off with a Multiplier. Like the Table field, Multipliers are very efficient and low overhead relative to something like Repeaters. Use Multipliers when you need to repeat a single input multiple times, optionally with a min and max number of inputs. Lets say you are building an employee directory, and each employee has between 1 and 3 email addresses. Rather than using 3 separate email fields, you would use 1 multiplier field and specify min=1 and max=3. Repeaters These are infinitely flexible in terms of what they represent, but each row of values is technically a page in the system. As a result, with the flexibility comes significant overhead. This is really only an issue when the quantity of repeater items gets high, or when you have lots (thousands) of pages using repeaters. I recommend repeaters for setting up things like homepage carousels. For example, if you go to the Villas of Distinction homepage, there are 3 separate repeaters in use on that page, each holding a photo, title, description, link. The client can have as many items in each of those sections as they want. Currently it looks like the first repeater as 6 items, the 2nd has 2, and the 3rd has 6. The possibilities of what can be represented with repeaters is endless, but look for potential alternatives when dealing with large quantities (whether large quantities of repeater items, or large quantities of pages using repeaters). PageTable This is one of the ProFields that is available for free (thanks to Avoine sponsorship) on the ProcessWire dev branch. Meaning, it'll be available for everyone to use as part of the core in ProcessWire 2.5. And you can use it now if you don't mind running the dev branch. PageTable has all the flexibility of repeaters, but with lower overhead from the admin/input perspective. Rather than trying to bundle all the inputs on one screen, PageTable shows you a table of items and you click on the item to edit it in a modal window. This enables it to be a lot more efficient from the admin UI perspective. It's also more flexible than repeaters are in terms of where you store your items. PageTable lets you choose where they should live, whether as children of the page being edited, or as children of some other parent page you designate. They might be a little more work to setup than repeaters, but I think that most situations where you need the flexibility of repeaters may be better served by PageTable. PageTable still can't compete with the speed and efficiency of Table or Multiplier, but consider using PageTable anywhere that you might have used Repeaters before. Repeaters and PageTable are fundamentally different from the admin UI/input perspective, so you'd want to compare them yourself to see what suits your individual input needs better. PageTable involves more clicking to create and edit items, making Repeaters potentially faster for entering data rapidly. But PageTable will scale much further in the admin UI than Repeaters will, so I would personally favor PageTable in more situations than Repeaters.

i-coder-not-writter.com

It sounds like this is more multi-language/similar-site, rather than actual multi-site. You mentioned all the domains describe the same content (for the most part) so I would probably take the "multi-site" out of your thinking about it, because it's only multi-site so far as it is multi-language. I'd use the dev branch, purely because it's going to take you a lot farther on the multi-language side. It should be plenty stable, but you'll just have to use extra care when updating (i.e. test things out on your own before upgrading a live server). If you could, I would try to do this all on 1 domain rather than split among multiple domains, but I'll assume that's not an option. But it'll be workable either way. If using multiple domains (or subdomains), you'll only need to install the LanguageSupportPageNames module if you want to have the same pages use language-specific names. I'm guessing you'll want that. However, you'll want to set the $user->language yourself, based on the domain/subdomain, rather than any other factor. You can do that with code like this at the top of a common include/file for all site template files: // grab the subdomain, i.e. "en", "de", "at", etc. list($languageName) = explode('.', $config->httpHost); // sanitize it just for good measure $languageName = $sanitizer->pageName($languageName); $language = null; // attempt to find a language with the same name if($languageName) $language = $languages->get($languageName); // if no language matches, then we'll assume 'default' language. if(!$language || !$language->id) $language = $languages->get('default'); // set the language to the user $user->language = $language; The above is essentially serving as your "multi-site" code, forcing the language to match the subdomain. You'd want to remove any other multi-site solutions. You'd want to use multi-language text fields where possible. When using multi-language textarea fields where you need rich-text editing, I suggest installing the InputfieldCKEditor module and using it in inline mode. This scales much better for multi-language environments than TinyMCE. For situations where you need different images per language, you can use the tags feature to devise your own matching method (perhaps using the language name as the tag), or you can use language alternate fields. For situations where you have a page available in one language and not another (or some and not others) then you can simply make them active or inactive from the checkboxes on each page's "settings" tab. To summarize, I would treat this site purely as a multi-language site, and would probably develop it without considering the multiple domains/subdomains. Then when it comes time to launch, point all those domains at the same site, but use the $config->httpHost trick above to set the language based on the subdomain its being accessed from.

I lizen to mi sound ofe keybpard wun koding.

This is how html5boilerplate does it. the nice thing is it works without specifying your domainname and could easily included in your own default htaccess: # Rewrite "www.example.com -> example.com" <IfModule mod_rewrite.c> RewriteCond %{HTTPS} !=on RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC] RewriteRule ^ http://%1%{REQUEST_URI} [R=301,L] </IfModule> https://github.com/h5bp/html5-boilerplate/blob/master/.htaccess#L344

As for how to use the TemplateFile class, you've got it exactly right. You can access everything you set() directly from the var name in the file, such as $headline and $body, etc. If you prefer it, you can also use the setArray() method (inherited from WireData) to do something like this (though I think I prefer the readability of your version): <?php echo $out->setArray(array( 'headline' => $page->get("headline|title"), 'body' => $page->body, 'sidebar' => $page->sidebar, 'navigation' => $pages->find("parent=/") ))->render(); TemplateFile is the class that PW uses to output your templates. I actually don't use it very often in my own sites. That's in part because I work mostly alone and don't have to compartmentalize stuff quite as much as if the work was split. I do think it makes sense to use TemplateFile more and more as the size of the team grows and you need templates with limited access and scope (as a good thing). The strategy that I use does not have limited access and scope, but it is probably more efficient and less verbose than using the TemplateFile class. Though it's also a similar approach in many ways too. The way it works is that all the site templates pull in the same main markup file (main.php). That main markup file is looking for values to be set to the $page object… whether those values were set in PW, or by some other template. Templates may also modify the values (usually appending or prepending) before sending to the main template. If an expected value is not set, then the main template supplies a default. So templates really only need to supply values for those things that they want to change. This is what that main.php markup file might look like: /site/templates/main.php <?php // set default values for topnav and subnav. // these aren't PW fields, so we're just using $page to hold values that other templates can override if(!$page->topnav) $page->topnav = $pages->get("/")->children(); if(!$page->subnav) $page->subnav = $page->children(); // we want all templates to have jquery, main.js and main.css $config->scripts->add('jquery.js'); $config->scripts->add('main.js'); $config->styles->add('main.css'); // if a JS or CSS file has the same name as the template, then use it if(is_file($config->paths->templates . "scripts/$template.js")) $config->scripts->add("$template.js"); if(is_file($config->paths->templates . "styles/$template.css")) $config->styles->add("$template.css"); // now output the markup ?> <!DOCTYPE html> <html lang="en"> <head> <title><?php echo $page->get("browser_title|headline|title"); ?></title> <?php foreach($config->scripts as $file) { echo "<script src='{$config->urls->templates}scripts/$file'></script>"; } foreach($config->styles as $file) { echo "<link rel='stylesheet' type='text/css' href='{$config->urls->templates}styles/$file' />"; } ?> </head> <body id='body_<?php echo $page->rootParent->name; /* for targeting in CSS */ ?>'> <div id='topnav'> <?php echo $page->topnav->render(); ?> </div> <div id='subnav'> <?php echo $page->subnav->render(); ?> </div> <div id='bodycopy'> <h1><?php echo $page->get('headline|title'); ?></h1> <?=$page->body?> </div> <div id='sidebar'> <?=$page->sidebar?> </div> </body> </html> Then all the other templates in the site customize the variables that get populated, and they pull in the main template. For instance, the homepage template: /site/templates/home.php <?php // we don't want subnav on homepage, so make it empty $page->subnav = new PageArray(); // list the 3 newest news items in the sidebar $page->sidebar = "<h2>Latest News</h2>" . $pages->find("parent=/news/, sort=-date, limit=3")->render(); // since it's the homepage, we'll add a masthead photo above the body if($page->photo) { $photo = $page->photo->size(600, 200); $page->body = "<img id='masthead_photo' src='{$photo->url}' alt='{$photo->description}' />" . $page->body; } // add a note about when it was last updated, just for kicks $page->body .= "<p>Last updated " . date('m/d/Y H:i:s', $page->modified) . " by {$page->modifiedUser}</p>"; // include the main template include("./main.php"); I also want to mention that main.php isn't actually used directly by any pages... I don't even keep it as a template in PW. Though you certainly could. But I just use main.php for inclusion by other templates. That's the approach I use most often anyway. What other approaches to people use?