Leaderboard

Amusing mis-spelling there - wonder if it was intentional or iPhone

This case study relates to the topic here: http://processwire.c...ndpost__p__8988 about creating an archive of 'stories' about how PW has helped in relevant real life scenarios. Website: http://www.ray-dale.com RayDale Multimedia Ray Dale is a multimedia designer. His portfolio website was 2 years old as of March 2012 and in need of a refresh. He found that the content management for his website was more time consuming than he wanted and the website was generally slow in performance and complex to update. Ray needed: A website that could showcase his latest work with separate portfolio content types The ability to show lots of images and videos in each section Complex interlinking between each portfolio item - where each item would belong to a number of simultaneous categories To be able to publish a number of pages under various sections on the website To have a condensed navigation structure - not over-facing the user with navigation A blogging space that was easy to update To gain complete control over the HTML, CSS & JS markup and therefore the design of the website The ability to take more control over the admin experience - without using a host of plugins - so that the CMS could be used for clients to make their lives easier Speedy performance - even if a shared hosting platform were used Good site security The previous solutions Ray was previously using Drupal as a content management system. Drupal is a great system, it’s incredibly flexible, it can be made faster and using template overrides, almost complete control can be taken of the HTML and CSS output. However, the process to achieve any of this is time consuming and clunky from a web designer / front end developer perspective. Drupal was also going to require a number of plugins to be installed to achieve a lot of the required functionality. Ray tested migrating his website over to WordPress. WordPress is another fantastic blogging system with light CMS functionalities. WordPress is generally easier to use than Drupal and a lot of control over the HTML & CSS markup can be delivered - in a much easier manner than Drupal. However, WordPress is still light on CMS features in the admin system. This means that it is difficult without either using a lot of plugins or custom php development (using the WordPress API) to have custom content types and fields. The decision to use ProcessWire Having searched around for an alternative to Drupal and WordPress - revisiting other CMSs that Ray had also previously used - Ray eventually landed on ProcessWire having read about it on a forum. Right from watching the initial video produced by Ryan Cramer (the creator of ProcessWire) Ray was intrigued by the possibilities that ProcessWire seemed to offer - effectively solving all of the issues currently faced. To summarise ProcessWire offered: Custom content types in the admin Custom field types in the admin Good control over media uploads A simple to use admin system A neat and simple API for custom frontend / backend development A customisable admin experience The ability to have a custom admin url Complete control over HTML markup Good security with flood control A powerful and flexible templating system (that was also simple) Ray was extremely impressed by the features that ProcessWire offered, however, many CMSs look great until you actually start using them - where the unnecessary complexities, weak architecture and terrible, bloated functionality often start to appear. The functionality seemed so promising that a gamble was taken to build the Ray Dale Multimedia website - with very little time now available - to ProcessWire and test how it performed. Building the website Having built the original Ray Dale Multimedia website in Drupal, then converted to WordPress before deciding to gamble on ProcessWire - Ray now had very little time left to build his portfolio website. As a testament to the ease and speed of using ProcessWire - he was able (with a little help from articles in the forum) to rebuild the Ray Dale Multimedia website in two days of effective full time development. This included all of the content creation and learning the new system - with the inevitable (but surprisingly smooth) learning curve. Enabling complete control over output ProcessWire allowed Ray to write HTML and CSS without any of the interference you get from other CMS systems. So, Ray was able to use the following frameworks of his choosing: HTML5 boilerplate jQuery Modernizr Masonry A customised version of the 960 fluid grid system PrettyPhoto for lightbox images Less - to create minified CSS Though it must be said that literally anything can be used as ProcessWire makes no assumptions on the frontend - even on the Javascript framework. Quick and easy API One really pleasant surprise was the jQuery influenced API that ProcessWire offered. For example you can use php queries such as: $pages->find("selector"); $pages->get("selector, path or ID"); to find content in the system - you can even filter your queries by template type, fields attached to that item, etc. You can even use a range of selector operators. The API effectively works as a super powered and infinitely more flexible alternative to the WordPress loop. Cross referencing pages easily Complex cross-linking between portfolio items was needed so that capabilities, technologies and services could be linked to each item. It was easy to create a taxonomy system that worked the exact way required once the fundamental concept of how pages work in ProcessWire was understood. Building navigation that works Unlike a lot of CMSs that work effectively as ‘bucket systems’ - meaning that content is separate from any kind of structure or hierarchy by default in the system - whereas everything in ProcessWire is a page and arranged hierarchically. Whilst this may seem strange and restrictive to some used to the aforementioned ‘bucket systems’ - it works incredibly well and enables you to build navigational structures that are easy to plot a current location in. It is also something easy enough to break away from if you want a more ‘bucket’ type system. For example, in Drupal and WordPress it can be very difficult to highlight the navigation on a website if you are using custom content types. Try using custom post types in WordPress and keeping your navigation tracking which page the user has landed on - it’s extremely difficult without a fair bit of custom development (this is true as of the time of writing - WordPress 3.3.1). Because ProcessWire uses a structure and hierarchy by default - this structure makes building navigation that can track the current page very simple. Easy / flexible admin system The admin system in ProcessWire was easy and fluid to use, logical and stable. The admin system can also be overridden with templates (there are already some great community contributed templates). Modules used Whilst ProcessWire has a number of contributed modules from a thriving and helpful community - absolutely no additional modules were needed. All functionality on the website was achieved from a vanilla version of ProcessWire. Performance Another area of importance was the performance of ProcessWire. Again, Ray found this aspect to be well covered with built in caching capabilities that were thoughtfully included ‘out of the box’. The caching was simple to enable on templates and fields. The memory footprint of the Ray Dale Multimedia website was a third of that of Drupal on the same website without using addon caching plugins. Challenges The only real challenge faced was understanding that ‘pages are everything’ in ProcessWire. You build categories, taxonomy, articles, blog systems with the ‘page’ (and any fields it contains) being the basic building block for all of this. ‘Pages’ in ProcessWire can be attached to templates and injected with fields to enable the creation of literally anything conceivable. However, understanding this concept takes a little work for people used to other CMSs such as Drupal, WordPress and Joomla. However, in context - and compared to other systems - this learning curve is still fairly easy. There are so many other time savers that this learning curve becomes negligible. The other area that Ray had to understand about ProcessWire was that there aren’t any template system paradigms that exist in Drupal and WordPress. Other systems have parent and child templating systems with default parent templates that can be leveraged, however, because ProcessWire makes no assumptions on how you are going to build a project (being a true framework) you currently need to create your own template files. This is made easy by good documentation on the ProcessWire website and a decent set of ‘starter’ template files that come as part of the default install. Conclusion ProcessWire was an absolute dream to work with. Ray found it to be very stable, well thought out and hugely flexible. So much so in fact, that Ray has decided to standardise on using ProcessWire for upcoming web design projects. The flexibility and simplicity of the admin system, combined with power in frontend development that ProcessWire provides is something that Ray found to be liberating and more importantly ‘best in its class’.

I committed a couple small additions this morning: 1. Fieldset indentation in the template editor. Hard to describe, but I needed some way to make the grouping of fieldsets a little easier to see in the asmSelect list in the template editor. Here's a screenshot which describes it better than I can: 2. The InputfieldCheckboxes field now supports columns. This would typically be used if you had a Page reference field using the Checkboxes input. When editing the field, you'll see a new option on the 'input' tab where you can specify a number of columns you want it to use. This is just a way to tighten things up for when you have lots of short-labeled checkboxes (see bottom of screenshot).

Not at present, but definitely interested in doing that for the future. It's just a matter of time/resources and putting it towards the stuff that matters most in the short term. Longer term it would be really nice to have something like this, especially as PW gets used more and more as a framework. I would version control your /site/templates/ and /site/modules/, but not your /site/assets/ as they are tied to DB entries. Though if you combine it with a DB export for each commit, then that would solve it. But this is something we'll have built-in version control for, further down the road.

Thanks Pete, sounds like we should definitely go ahead and add the octits-stream to keep the firefox happy. I will plan to add this. Thanks for your research and testing here.

Not sure if this is the best place to post this but here goes anyway. As a followup to my initial installation of pw, I just did another and sat looking at the final set of messages from the installer for a while thinking something looked a bit, err, disjoint with a couple of the messages. In the list were these two, not next to each other in the list, but in this order... Now that the installer is complete, it is highly recommended that you make ./site/config.php non-writable! This is important for security. There are additional configuration options available in this file that you may want to review: ./site/config.php Now, as a total newbie to pw, if I do the first I won't be able to do any editing that might be needed in the second part of the message without undoing what I just made read-only, then applying my edits and making it read-only again. Ok, I guess that in most cases, the second stage will be a review with no editing needed. But that might not be the case -- and might even change in future versions (another guess.) So perhaps these two could be rationalized into one, something like... "Now that the installer is complete, please review and, if needed, update the contents of ./site/config.php before marking it read-only. NB: For security it is highly recommended that you make ./site/config.php non-writable!" Would this simplify things for newbies?

Pure fluke. I figured that there must be something wrong with the headers coming back from the server since it worked on other servers, and found a blog post where someone said it was good practice to give the browser an idea of the content type (but alas I didn't bookmark it... think it was a search for "xhr header" so if I find it I'll post the link. From my days working with an old download script, octet-stream was the default mime-type - think of it as a slightly lazy catch-all. You could specify the precise file type, but you would then need to have a mime-type table to send the right header for every possible filetype allowed by a field (which is nearly impossible as the user can specify their own types!), whereas in my experience octet-stream was fine for all cases I've run into in the past with those sort of scripts. In fact, since this was a Firefox issue, this post seems rather more helpful than the one I originally found as there's a section where it attempts to work out the mime type: EDIT: https://developer.mo..._XMLHttpRequest EDIT2: Although Mozilla's example above defaults back to plain text, so not the best example as what we're sending is a file. There's a brief description of octet stream here: http://kb.iu.edu/data/agtj.html

You can assign fields to templates like this: $template = $templates->get("some_template"); $template->fields->add("newfield"); $template->fields->save(); this code is taken from here http://processwire.c...bles/templates/ So, just make an array with all the templates you want the field to be on, and go for it $ts = array("home", "basic-page", "search"); foreach($ts as $t){ $template = $templates->get($t); $template->fields->add("newfield"); $template->fields->save(); } EDIT: the field will be on the last position of each template

Hey neil (are you neil?), I'd say go check out the source of configurable modules. The code for building the configuration options is there - you'd only save the fields into db: // this is a container for fields, basically like a fieldset $fields = new InputfieldWrapper(); // since this is a static function, we can't use $this->modules, so get them from the global wire() function $modules = wire('modules'); // Populate $data with the default config, because if they've never configured this module before, // the $data provided to this function will be empty. Or, if you add new config items in a new version, // $data won't have it until they configure it. Best bet is to merge defaults with custom, where // custom overwrites the defaults (array_merge). $data = array_merge(self::getDefaultData(), $data); // showModal field $field = $modules->get("InputfieldCheckbox"); $field->name = "showModal"; $field->label = "Use modal window"; $field->description = "Whether open pages in modal (overlay) window or goes to traditional administration."; $field->value = 1; // providing a "checked" value for the checkbox is necessary $field->attr('checked', empty($data['showModal']) ? '' : 'checked'); $fields->add($field); return $fields; This is from latest AdminBar by @apeisa. You can see the '$field' part, where the field is built. You probably only run $field->save() at the end instead of current $fields->add() and you have just created field via code Adding fields to the template will be probably close to the ->add() call, and I'm totally not sure about reordering them in the templates via code, you might need to play with this a little.