Leaderboard

Some 2.3 updates now present on the ProcessWire dev branch at GitHub: New session handling features ProcessWire now supports alternate session handlers and includes a new module that provides for managing them in the database, rather than the file system. To enable, you just install the SessionHandlerDB module, and that takes over as the session handler. The advantage of a database session handler is that it can potentially be more secure in some shared hosting situations. It also enables ProcessWire to report on active sessions in the admin, so the new handler also adds a "Sessions" option to your "Setup" menu that gives you a table showing everyone browsing your site and where they are. I plan to expand upon this a bit more though. The new session handling interface also makes it possible for you to add modules that would move session handling to something like memcache, Amazon Dynamo DB, or really anywhere. New password security updates ProcessWire now uses Blowfish hashing for passwords when you are on PHP 5.3 or newer. If your database were to ever be compromised, this provides better protection from someone attempting to reverse engineer passwords from the hashes. Beyond blowfish hashing, we still use double salting as before (with one salt on the file system, and other unique to each user in the database). For existing accounts, the blowfish hash doesn't actually take effect until you change your password, so it'll be a gradual transition for many of us. Though the admin does give you a reminder every now and then. However, once you go blowfish, you can't go back, so don't develop a site in PHP 5.3 and then launch it to a PHP 5.2 server, unless you don't mind changing your password(s). And more… Addition of the WireHttp class, which provides ability to perform POST requests from the API. ImageSizer now uses better image type detection rather than image extension detection (via @teppo) WireArray now supports ability to sort by multiple fields at once as well as implements 'limit' and 'start' in selectors (via @nik) Updated to latest jQuery and jQuery UI (via @mindplay-dk) Removal of some big bottlenecks from FieldtypeRepeater (via @nik) Transparent GIFs are now supported during resizes (via @mrx) Support for 'min' and 'max' with integer and float fields Support for HTML5 'number' type with integer and float fields Support for HTML5 'required' attribute with many fields The datepicker in the datetime fieldtype now supports ability to specify selectable year range Several other updates in the commit log.

Here's a little preview of the 'Save Page' settings screen where you can configure forms to publish to pages.

I just posted a few lines regarding CMS systems on wep.appstorm / tut+. and I had to tell about my last cms system i my life.. processwire.. Head over, or read my post right here.. http://web.appstorm.net/general/weekly-poll/weekly-poll-have-you-ever-moved-your-site-to-a-new-cms/ ---------- snip snip ----------------- CMS there is many out there, some really nice and fast, and some huge and evil. A friend of mine told me about my (now) last CMS/CMF system Im going to use.. ProcessWire by Ryan Cramer is a amazing system, with huge possibilities and scaling factor.. The most powerfull thing in it, is that its you that is doing most of the markup, but with the latest release of his formBuilder, even someone with no programming skils, can du amazing webforms.. without coding anyting… The API reminds a great deal about jQuery, and thats not a bad thing.. But head over to http://processwire.com/ and fork a copy at GitHub.. Its a MUST try.. (and love…) my 2 cents from the grim north… ---------- snip snip ----------------- and have a nice sunday..

ProcessWire should scale very nicely as things grow. You shouldn't see slowdowns from quantity of pages unless you've got a bottleneck in your code. By that I mean primarily: using selectors without appropriate limit statements. Repeaters should also be used carefully like Teppo mentioned. Though the dev branch resolves the major bottleneck there that Nik had found and helped to fix. I don't see any problem with repeating your site over multiple servers so long as you are designating one as the master where actual changes are made. Pete may be able to speak to this better than me, but apparently some web hosts scan scale your server virtually, to quite a large scale that [apparently] spans several servers while behaving as one. But this is something I've not experimented with yet. This is actually already in the dev branch. Session handling can now be done by plugin modules, and it comes with a database session handling module. But you can pretty easily implement other types of session handlers using the same interface.

This is what I was referring to. But anyhow, I decided to go the more adventurous route and learn how to build an Inputfield-type - I haven't attempted to use my icon-selector with a Field on a Template yet, but my hope is that the icon-selector and preset color-picker would be useful for more than just the TemplateDecorator itself. To me, this is one of the most important values in ProcessWire: the idea of building small, reusable features - as opposed to large, self-contained concepts... I believe this is the core reason why platforms such as Drupal or WordPress need hundreds of similar modules for the same things, to satisfy everyone - when you build out an entire concept, it's set in stone, and it doesn't fit everyone's needs, so every shop-module (for example) addresses a slightly different set of needs. When we provide the building-block features instead of self-contained concepts, this enables the developer to rapidly apply those features to solution-specific concepts. The module-concept in most other CMS suffer (by design) from what I've been calling "conceptual lock-in" for some years now - PW doesn't suffer from this, and as such will hopefully see smaller numbers of more lightweight and generic modules, from which developers can design the concepts. (sorry for side-tracking, but I had to put that in writing!)

(Edit: This just got deprecated , but I'll still leave it here - see "Part 2"). Go and see Setup -> Fields -> body. What's the type of the field? I'm guessing it's "Textarea" as there doesn't seem to be fields for different languages in the database. That kind of selector would work only for fields of type *Language, "TextareaLanguage" in this case most likely. You can change the type safely, but still after that for the selector to work in a reasonable way you'd have to input some content in the very language you're using in your search. But that was actually what you must have been trying to do anyway. (..a few hours later..) Part 2 Had another idea a bit later and while the earlier explanation could have been right, there's another possibility as well. And I think this is much more probable than the first one as I can't understand why you'd be using a selector like that if you didn't already have actual multilingual data in there - stupid me. So now I'm thinking 1029 is the id of you default language (see Setup -> Languages -> default - what's the value of id parameter?). That special kind of selector would only work for languages other than the default one as its field is named just "data", not "data1029" for instance. So when the language is set to default ($user->language->name == 'default'), you'd have to use a regular selector without the ".data{$user->language}" part (or just ".data" without the id, I think). Next part will follow in the morning - hope not.

Packt Publishing is offering a free eBook for those that register or sign in during today http://www.packtpub.com/

Nik is right about this. You probably want to change your selector to something like this: $field = $user->language->isDefault() ? "body" : "body.data" . $user->language; $matches = $pages->find("$field*=$q"); That will force it to not consider the default language in the matches at all. However, most of the time you should just do this, which already takes languages into account: $matches = $pages->find("body*=$q"); So whether the user searches for "Beer" or "Cerveza" they will still get to the right page. If you exclude the default language, then that fallback never happens.

Sorry, can't really answer your first question, haven't seen a setup that huge so far. So far large sites have worked pretty nicely (talking about <100,000 pages here) with the exception of repeaters causing trouble here and there. I've heard that there are some really nice speed improvements coming regarding those, though -- but I'd still generally encourage you to avoid them when building this kind of site (unless someone can prove me wrong on this one.. ) Anyway, first of all I'd suggest you to take a good look at ways to maximize site speed without applying any complicated tricks -- cutting HTTP queries to minimum, compressing CSS, JS and images, using cache as effectively as possible etc. Also: if you need to host your music videos yourself (though hosting at YouTube or similar service would generally be a much better solution) I'd create an external server just for static content like that; "videos.example.com" or something like that. All the big guys are doing stuff like this already. Regarding splitting PW site on two (or more) servers, that should be possible in theory, but would require a lot of work and could be a little "hacky." The main problem here would probably be assets; you could have multiple servers running PW while still sharing one database server (and a load balancer in front of those servers) but you'd need to find a way to keep assets synchronized. I don't really have a viable solution for that at the moment, though it's something I've been looking into too -- currently handling stuff like that with rsync, but that's nowhere close to "real-time." I think someone somewhere (?) mentioned that PW sessions can also be saved in database, which would help a bit here - don't know if that feature is still in dev branch though. Another solution would be to run a main site on one server + separate "subsites" on others (example.com, genre.example.com, anothergenre.example.com, users.example.com, auth.example.com, comments.example.com etc.) but that'd make communication, searches etc. between those sites way more complicated and at least require some kind of SSO solution. To be honest quite often it just makes sense to keep things running on one server (with the possibility of separate servers for database + static files as mentioned above) and when requests pile up just put some extra muscle on those servers. That's another reason to love virtualization.. keeps things nice and flexible Edit: the more I think about this, the more I start thinking that the viability of having one PW site run on multiple servers simultaneously is related to how often assets are added / changed / removed. If your typical user doesn't have the right to manage assets, it would be relatively simple to implement a server-side watcher that would sync assets between sites / servers. Rsync (for an example) has an option to only sync files that have been added / changed, thus you wouldn't have the need to sync all the files between servers whenever something is changed. In this setup cache files could cause some trouble, though -- not sure how to handle those properly. A filesystem watcher could be a self-made server-side combination of rsync + cron (non-realtime) or some of the already available applications, such as Lsyncd. Quite possibly you could also have the watcher work as a PW module, hooking into file save operation and then invoking rsync / other sync method via exec() -- not sure if there's an easy place to hook into yet though, just throwing in some random ideas here. Oh, and all of these ideas rely heavily on you having complete control over your servers. I hope that's the case. They're also based on my relatively low knowledge of PW + server administration, so there might be a much better solution available..

Commenting on related blog posts is very effective and easy way to promote ProcessWire, good job. I recently noticed this comment by Mindplay too: http://www.sitepoint.com/whatamp039s-your-favorite-content-management-system/#comment-1060340

I should really start using this. My current method is to use Chrome's inspector to see the real field name from source html...

Somehow I missed this post before... nice module Soma! Thanks! And thanks Alan for bringing this up again

Now I look at this I see it makes sense, as we're allowed to simply type the name of a field to use it rather than some "Field = my_field" syntax (lovely PW ) I can see that whitespace could be weird to deal with so it makes sense that it must not be used; to explain this produced an error: $slideshow = $pages->find( "parent=/work/, slideshow_part_of=1, image_special.count>0, slideshow_copy != ''" ); but this was perfect $slideshow = $pages->find( "parent=/work/, slideshow_part_of=1, image_special.count>0, slideshow_copy!=''" ); the difference being the spaces either side of the != in the final test. I am guessing this is stated in the documentation or obvious or something a PHP person would know and that's how I missed it (not great at RTFM, not great at seeing obvious things and not a PHP hero ) Anyway, I just thought I post this in case it helps anyone else out fitting the above description. Totally loving the speed and power of working with PW.

Thank you very much for this Module Soma! Just seeing the real Field name is often a lovely time-saver Thanks!

Hi Soma, love your plugin, timesaver! just quick note: the link on the http://processwire.com/download/modules/ links to the old forumpost, maybe ryan can update it to the new one so more people can enjoy faster development