Leaderboard

I'm not exactly sure what you're thinking "combine" means here, but this field does exactly what the description says; it grabs data from other fields, mashes it all together into one big blob of (JSON) content -- and that's just about it. One very simple (yet sometimes very practical) use case is if you've got, say, 15 different text fields and you need to find pages that contain value "john doe" in any of those. Instead of doing this: $john_does = $pages->find('field1|field2|field3|field4|field5|...|field15%="john doe"'); .. you can create a cache field, select all of those fields to be cached in it, and then do this: $john_does = $pages->find('my_cache_field%="john doe"'); Not only does this look clean, in certain situations it can wildly improve query performance.

One option is to install a self-signed SSL Certificate on your local machine. There are numerous instructions on how to do this on the Internet. I have referenced one that applies to Windows users to get you started. http://www.howtogeek.com/107415/it-how-to-create-a-self-signed-security-ssl-certificate-and-deploy-it-to-client-machines/

I have no problem with spaces in passwords. Can't say I've ever thought to put spaces in passwords, but it makes sense. I'll update to support that the next time I'm in the code for that module. As for logging in with email address, PW uses the username as the unique key for all users. Users are pages, so this is for consistency with the pages system as a whole. I think maintaining this consistency is preferable in keeping the whole thing as simple as possible. Not to mention, 'name' is a built-in property of every page, whereas 'email' is just a custom field in the template (it's technically possible for it to not exist).

If you guys are using 2.3 or 2.4 you might prefer: $this->wire('key', 'value'); rather than $this->setFuel('key', 'value'); and $this->wire('key'); rather than $this->fuel('key'). The "fuel" terminology is meant mainly for internal use rather than public API. It'll work, but I think it makes code more complex than it needs to be, versus just using that single wire() function for everything.

If using the latest version of PW with the new default admin theme, it doesn't display the Inputfield label if there is no description – just shows the checkbox label. From the API side, you can also specify $field->label2 as something distinct from $field->label, where $field->label2 is the second label (the one for the checkbox).

Not even Google Analytics reveals the vast majority of phrases used to arrive at your site. My understanding is that technically it may be for https, but strategy wise they are doing it to increase search relevance by keeping all of us more focused on content than keywords. Source (see section "100% not provided") This should be expected, as no PHP is executed on a ProCache request.

Just launched a new Processwire site, http://luxcommunications.ca Comments? Feedback? As always, if you find any bugs or problems please let me know.

I've been working on this one for a few months and just launched it this morning: http://villasofdistinction.com I also did the previous iteration of this site, 5 or so years ago (which was running ProcessWire 1.0). The new site is powered by ProcessWire 2.4 (2.3 dev). The site is responsive and designed for a good experience on both desktop and mobile. While I did all the development, the site's design/look and feel was created by the client (they have their own internal design agency). Most of the work in this project was actually not anything you can see on the front end. Instead, most of the work went towards back-end management, workflow and web services. The client has a large number of editors and agents that needed various capabilities, workflows, feeds and such. So there's a lot more going on here in terms of a management platform than in the previous iteration... and that's mostly what kept me busy for so those few months. Modules used here: Foundation 4 Profile All In One Minify (AIOM) FieldtypeMapMarker (with MarkupGoogleMap) Pro Cache Form Builder Hanna Code Redirects Selector test Changelog Version Control for Text Fields Batcher Admin Template Columns CKEditor Select Multiple Transfer CollagePlus And a few custom modules

@ryan: the issue I was having was (once again) related to API use, in which case access control affecting things makes sense.. and yes, since then I've been running modified core code (include=all) and at least that particular issue seems to be fixed By the way, I only just noticed your post and had already written a slightly more extensive test script to see what exactly happens when I work with repeaters over API without aforementioned fix. I posted it as a public gist here, if you want to take a look: https://gist.github.com/teppokoivula/8889040. Still far from a proper test case and a bit disorganised, but at least it helped me figure out what works and what (possibly) doesn't.. It's very much possible that I'm doing something wrong here and/or should really do even more manually, but so far it seems to me that repeaters could use some extra garbage cleaning here and there -- and perhaps some simplification especially when it comes to creating and/or removing repeater fields. It should also be noted that I couldn't find any "official" documentation either, so the way I'm doing this at the moment is partly copied from core code, some if it came from examples adrian (I think) posted somewhere etc.

You guys are tough. My impression is that the site is awesome, something different with lots to discover and great visual rewards. It made me want to stick around. I've found this site and the one that Felix posted to be some of the most visually interesting and engaging sites I've seen recently.

Thanks for the debugging work you did with this. You are right that the status<Page::statusMax should be replaced with an include=all. That status<Page::statusMax is the old version of include=all ... what we used before we had include=all. It still works just fine, except it doesn't bypass access control the way include=all does, because access control used to be handled differently. So it looks like the behavior you saw there could occur if it was executed from a non-superuser account. Just to confirm, replacing it with "include=all" fixed the issue from what you can tell? I will make the change here, as it should be include=all regardless.

The error message suggests that Twig is trying to call $page->template as a method, like $page->template() -- which doesn't exist.

This is one of those cases where an SQL query would be easier. WHERE DAYOFWEEK(date) = '6' But it probably isn't worth it to do an SQL query for such a simple situation, so you might be best just removing the non-Saturday dates from the results. $results = $pages->find("date>=2014-01-01, date<=2014-12-31"); foreach ($results as $result) { if (date('l', $result->date) != 'Saturday'){ $results->remove($result); } }

I'm not getting any perceptible slowdown with 100+ fields here. Soma do you have any modules hooking into the rendering on that screen? Considering how quickly the dropdown navigation versions can be generated, I'm guessing the slowdown may have something to do with the calculation of # templates and # pages that are shown. If I can get a copy of your database dump, I could import here and test. These were actually just converted to AJAX yesterday, so that they don't have to be loaded/rendered on every admin page request. This also removes the 100 field/template limitation that we'd imposed on it.

I think these guys covered it really well, but here's an overly simple alternate example in case it helps. class YourModule extends WireData implements Module, ConfigurableModule { public static function getModuleInfo() { return array('title' => 'Your Module', 'version' => 1); } const defaultValue = 'renobird'; public function __construct() { $this->set('yourname', self::defaultValue); // set default value in construct } public function init() { // while you need this function here, you don't have to do anything with it // note that $this->yourname will already be populated with the configured // value (if different from default) and ready to use if you want it } public function execute() { // will return configured value, or 'renobird' if not yet configured return $this->yourname; } public static function getModuleConfigInputfields(array $data) { // if yourname isn't yet in $data, put our default value in there if(!isset($data['yourname'])) $data['yourname'] = self::defaultValue; $form = new InputfieldWrapper(); $f = wire('modules')->get('InputfieldText'); $f->name = 'yourname'; $f->label = 'Enter your name'; $f->value = $data['yourname']; $form->add($f); return $form; } } If you have the need to manage several configuration values, then you can save yourself some time by using a static array of default values like in the examples before mine. Also this: foreach(self::$configDefaults as $key => $value) { if(!isset($data[$key]) || $data[$key]=='') $data[$key] = $value; } could also be written as this: $data = array_merge($data, self::$configDefaults);

This turned out to be an issue with the order of variables returned by core TemplateFile::getArray. It was doing an array_merge which gave preference to API variables, preventing them from being overwritten. Maybe that's a good thing in general, but I don't think we want that limitation. I went ahead and changed it in dev. Now it gives preference to local variables, which enables Hanna Code to provide the behavior it was supposed to.

Google this: site:processwire.com/talk date selector

This is super cool!

Yes they are supported now and will continue to be. Though I'm hoping people will convert the themes over to AdminTheme modules. It's easy to do, and provides the benefit of having multiple-admin themes installed at once. When more than one admin theme module is installed, ProcessWire adds an admin-theme selection box to every user's profile screen. To convert an existing admin theme to a module, just move the files into /site/modules/AdminThemeName/ (replacing the Name part with the name of the Admin theme, i.e. AdminThemeTeflon). Then create a new file in the same directory called AdminThemeName.module (again replacing the Name part). All that needs to be in that file is this (I'll continue to use Teflon as the example name): <?php class AdminThemeTeflon extends AdminTheme implements Module { public static function getModuleInfo() { return array( 'title' => 'Teflon Admin Theme', 'version' => 1, 'summary' => "A nice admin theme.", 'autoload' => "template=admin" ); } } Of course, the AdminTheme can go a lot further if you want it to. Examples include: having its own install() method to add new assets it uses (i.e. user profile avatar), adding its own hooks, creating its own API vars, having a custom configuration screen, or anything else you could do with any other module. But all of that can come later... all you need to do to convert an existing admin theme to an AdminTheme module is just to move the files and add the AdminThemeName.module file shown above. I haven't yet had time to look at this one, but it's on my to do list. Thanks for keeping me up to date on it. There's always a long list of issues to cover on GitHub, but we were at a point where all remaining issues were relatively minor, affected very few people, and didn't need to hold up release. I just didn't see any reason for people to keep downloading 2.3 when 2.4 is already more stable. We'll be covering remaining issues, like this one, with incremental versions, working through the list.

Just stumbled upon this: One-click App Deployment with Server-side Git Hooks.

What i really don't understand is how curly quotes would ever turn up as â because that is the html entity for the letter a with a circonflex. I'm assuming you've given a bad example here. If things show up correctly on the admin side there must be an issue with the rendering bits of the live site. Have you checked the encoding of the corresponding template file itself? Any textformatters on the field? What is your render code? Is there a url we can look at?

You can make up your own users system, and sometimes it's the simplest route to achieve something. But I would try to get it done with regular PW users first. You can always map fictional page names to usernames via URL segments. For instance, if you had a template called 'riders' and you enabled 'URL segments' in the 'URLs' tab of your template, then your /site/templates/riders.php file could have code like this: if($input->urlSegment1) { $rider = $users->get("name=$input->urlSegment1"); if(!$rider->id || !$rider->hasRole("rider")) throw new Wire404Exception("Unknown rider"); // display rider echo "<h1>$rider->name</h1>"; echo $rider->body; // ...or whatever fields you wanted to output } else { // display list of riders foreach($users as $rider) { if(!$rider->hasRole("rider")) continue; echo "<li><a href='./$rider->name/'>$rider->name</a></li>"; } }

My younger brother runs a business for textile finishing and custom textiles in germany: http://meridian-gbr.de Based on foundation 5, which it really made easy to realise the layout. Modules used: Page Image Manipulator by Horst

Hi One of our last PW projects. The client: a little café in our beautiful little town of Freising near Munich. Site ist not finished yet... Feedback and suggestions welcome! http://www.parkcafe-freising.de

Hey folks, just wanted to add this side project to the list of incredible ProcessWire sites. http://www.brenztapete.de/ http://www.brenztapete.de/2013/oggenhausener-sonnenuntergang/ It's a site where you can download Wallpaper, taken in my home town Heidenheim. The idea was to ask more photographers to add pictures but thats currently only a future plan. The whole site didn't took any longer than one evening. ProcessWire 2.3.x dev with ProCache Apeisas Thumbnailmodule for the cropped variations of the image Some Lazyloading JS magic Responsive CSS Grid. Anyone interested in a site profile from this page?

Nienburg Mittelweser is a Region in Lower Saxony/Germany. Our Job was to create an official campaign that engages young familys and skilled workers to settle down in Nienburg. The campaign tries to communicate the benefits of deceleration and living in an rural region in a sympathetic way. Apart from developing the whole Logo/CD/Imagery/Text our job was to create a Microsite that gives interested people a brief overview of the benefits of living in this region. The microsite is (of course/as usual) powered by processwire. http://einfach-lebenswert.net/ For those who don't speak german ( ) here are the 3 keyvisuals headlines translated in english: --> GROSSBAUSTELLE = Large construction site [in Nienburg-Mittelweser] --> KONSUMTERROR = pressures of a materialistic society [in Nienburg-Mittelweser] --> RUSH HOUR = Rush Hour

Reviving an old topic, as I'm seeing something similar here at the moment. Sadly my current setup is far from clean test case, so I won't be going into too much detail, except that it seems to have something to do with Pages delete() method. Simply put it doesn't find actual repeater items, so they never get deleted. For an example page /processwire/repeaters/for-field-359/for-page-1646/ gets deleted, while one below it at /processwire/repeaters/for-field-359/for-page-1646/1391714225-7472-1/ remains. This is the original code that won't work for me: public function ___delete(Page $page, $recursive = false) { if(!$this->isDeleteable($page)) throw new WireException("This page may not be deleted"); if($page->numChildren) { if(!$recursive) throw new WireException("Can't delete Page $page because it has one or more children."); foreach($page->children("status<" . Page::statusMax) as $child) { If I change that last line to this, repeater items are found and properly deleted: foreach($page->children("include=all") as $child) { I'm probably missing something here, especially since I've no idea why status selector is used here or why it doesn't seem to find the repeater page in question, but at least for me this fixes the problem. Might cause some new ones, though, don't know about that yet..

Congrats to Beate for being the 1800th user! You won a prize: New Checkbox Inputfield settings!

As being a active member of this sports club, i've been asked to take over the website-development, so i'm developing this site in my spare time. http://tbe1844.de Developed first with Twitter Bootstrap v.2, but then converted it to version 3, which went comparatively smooth and easy. Every section could be managed by the staff from this section by restricting admin access for paths to users. This is still in development, especially the event managment needs some engagement. It is planned that it should be easy to generate a view of events distinct to a section or team and display this in a calendar or list... I implemented also a ranking list for the beach volleyball teams. It is based on the ELO-system used by chess or table soccer, the ranking points you get for a win or loss are calculated based on the points for both teams before the game. The ranking list is private, so if you wanna take a look, send me a pn. Modules used: Image thumbnails Fredi Hanna Code (you can insert tooltips to persons and locations in the editor) Page edit per user Map Marker

Lately i've put together this rather standard website for a german beer brewery manufactory: http://schwarzwald-gold.com Design is all by me, except the logo, which was done by a graphic designer. The new Foundation 5 was used as base. For the slideshow i used layerslider, the client could create his own slideshows and assign it to every piece of content. The client wished to have configurable blocks of content, which i realised with repeaters that can be adjusted to display just text, text with a left or right aligned picture and can choose to include a slideshow at the end of the block. The contact form is based on the code from Soma.

Hi Manaus, how about adding page.template to $twigvars before the call, eg. $twigvars = array("page" => $page, "template"=>$page->template->name); then in your twig template having: {% if template == "project" %} disclaimer: i haven't tried this, i'm just thinking out loud.

I love how this happens. I run into something that I can't figure out, so I check the forum. Guess what? My question was asked and answered on the same day. Thanks guys.

Hey reno, You can set your defaults like this. Just put it before your init(): protected static $configDefaults = array( "defaultSelector" => "default value here" ); /** * Data as used by the get/set functions * */ protected $data = array(); Add this line to your inputfield: $field->attr('value', $data["defaultSelector"]); And add the following at the top of your static public function getModuleConfigInputfields(array $data) {: foreach(self::$configDefaults as $key => $value) { if(!isset($data[$key]) || $data[$key]=='') $data[$key] = $value; } You can then access this throughout your module using: $this->defaultSelector; At least that is how I have been doing it - maybe someone else has something cleaner Does that make sense? PS, Sorry for all the consecutive edits. I really shouldn't try to offer device when I am busy with other things and rushing EDIT Again - I just read that tutorial you pointed to and I see if uses: public function __construct() to set the default values. I haven't used that before. I guess I started by copying from other modules and never came across that approach. I guess there are a few different options, but construct does seem cleaner.

Thanks ceberlin! This is just a soft launch of 2.4, as I've still got some items to cover before telling everyone about it. However, I was feeling that 2.4 is already a lot better and more stable than 2.3, and that there's just no reason to have people download 2.3 anymore. So 2.4 is now the stable version, but it will still be getting some minor incremental updates for a little while. For those upgrading, be sure to read the upgrade instructions and additional upgrade notes.

CONGRATULATIONS TO 2.4 ! An opportunity to thank Ryan and all contributors again for this wonderful software!

@Anssi: sounds like an issue with secure connection. Google is using HTTPS for all search results and RFC 2616 clearly states that when going from HTTPS to HTTP referer header should not be preserved: One exception to this is referer meta tag, which Google is actually using to provide some basic referer information for browsers that support this -- namely the domain that a request originated from. There's not much information you can get out of that, though Simple test: open dev tools, switch to net panel (or whatever it's called in your particular flavour of tools), set up filter (if available) to only show documents, enable "sticky" logging ("Preserve Log upon Navigation" in Chrome) and click any Google search results. Only the originating domain should be included with request headers.

What a waste of time, but I have managed to narrow down the debug accordion/source truncation issue to the ProcessPageDelete module and this code: public function addJavascript(HookEvent $event) { $js = ' <script type="text/javascript"> $(document).ready(function() { $("li.PageListActiondelete a").live("click", function(el){ if(!confirm("Are you sure?")) { return false; } }); }); </script>'; $event->return = str_ireplace("</head>", $js.'</head>', $event->return); } I am still not completely sure why it is breaking things and especially why only on one installation, but what I did was move that JS code into it's own file and call parent::init(); to have the module automatically load the ProcessPageDelete.js file. I'll submit a pull request to Nico.

Speaking of the debug section, would you be opposed to this change so that it can be toggled closed again? $(document).ready(function() { $("#debug").accordion({ header: 'h3', heightStyle: 'content' }).hide(); $("#debug_toggle").click(function() { if ($('#debug').is(":hidden")) $("#debug").slideDown(); else $("#debug").slideUp(); var n = $(document).height(); $('html, body').animate({ scrollTop: n },'50'); return false; }); });

I want to share with you guys the final solution that I implemented for this newsletter. So, I decided not to use any system like Mailchimp or Campaign Monitor (thanks for these and other suggestions, anyway). I wanted an extremely simple system, and decided to built it with PW instead. Collecting the emails is done in a very simple way: when the user inputs the email, it is sanitized and, if it doesn't exist, a new page with the email as title is created under a parent called "people". Like this I get a nice list of emails in the page tree. After this, the user gets a success message, and is sent a welcome email. $email = $sanitizer->email($input->post->email); if(!$email) { echo $pages->get(1023)->not_email; } elseif($pages->get("title=$email") instanceof NullPage) { $p = new Page(); $p->template = $templates->get("person"); $p->parent = $pages->get(1015); $p->title = $email; $p->save(); echo $pages->get(1023)->confirm; //send the email $to = $email; $subject = 'Willkommen'; $message = <<<EOT ...(here goes the html of the welcome email)... This email (and also the future ones) has a link for an unsubscribing page that looks for the imputed email and deletes it: $pages->get("title=$email")->delete(); if($pages->get("title=$email") instanceof NullPage) { echo $page->byebye; } else { echo $page->error; } The newsletter itself is also very simple. In this case we decided that periodically, the administrator will choose some of the posts from the blog to build the emails. So, I created a page "messages" that accepts children pages with a template that has only a date field and a pages select field. To send a message, the administrator creates a new page under "messages", chooses the blog posts that wants to include, publishes it and presses view. Here she is presented with a sample of how the email looks like, and a button "send" on the bottom. The email is sent, and she is redirected to the PW admin with a success message. Again, I kept it very simple because we wanted limited functionality, and maybe it needs some adjustments. But It could be much more complete, with the alternative to write a text and put images instead of only choosing the blog posts, for instance. And maybe even turned into a module.