Leaderboard

We're aiming for soft launch this Friday and official a week later. Tried for last Friday but still had some issues to resolve + waiting on some things. I believe it's safe to start using now, but you'll still want to upgrade when 2.5 is official.

I've been working on a module to make it really simple to upgrade ProcessWire from one version to another. Especially as a way to make it easy to upgrade from PW 2.4 to 2.5, or to upgrade from one dev version to another. This tool supports upgrading between any branches of ProcessWire (currently we only have master and dev on GitHub). It will also let you downgrade your ProcessWire version, though no reason to do that. The module keeps up-to-date directly with GitHub, so it works as a long-term tool for every upgrade if you want it to. It works best if your file system is writable. However, if it isn't, the tool can still be used. It will still download the upgrade files to the server and then tell you where to move them. I should also mention that this module is somewhat inspired by a similar module Nico built awhile back called AutoUpgrade. So far I've used this tool to upgrade this site (processwire.com), the skyscrapers site, and the modules site (modules.processwire.com). Before releasing this officially in the modules directory, or suggesting it for production use, I'd like to get some help testing. If anyone has availability to help test this on non-production sites, your help is appreciated. It can be downloaded from GitHub here. As a bonus, it will also be a good opportunity to help test PW 2.5! Thanks in advance. What I'd really like to do as the next step with this is make it support upgrade by FTP. That would provide a nicer and safer solution for those that don't have writable file systems on their servers. This tool should be compatible with ProcessWire versions as far back as 2.3.4. I will also update it to support older versions than that if there's demand for it.

Ivan, always happy to oblige:-) The backend is not customized. It uses the Modesta Theme which we felt was a tad better than the default. We were under tight time pressures to launch the site and decided to skip any backend customization. For the time being, permissions are just for backend admin - web, magazine editorial. There was an idea we had mooted with roles for users who submit photos, but because of the launch deadline, we have deferred that bit for Phase 2. I am appending a screenshot of the backend, just to show you what we have done. The Block-System that you see, is for organizing the Home Page content. It has 3 regions [left, middle, right], very similar to Drupal's regions, in the template. Within each region, post excerpts can be added by the admin for control of the Home Page content. Magazines and Web Editorial, are organized by month. Trust that answers your questions.

Nice, Glad you got it working. Might be an ever so slight performance improvement by checking the page template before doing anything else. public function redirect($page){ $page = $event->arguments(0); if ($page->template == "blog_post" || $page->template == "gallery_post")){ $errors = false; // check notices for errors before redirecting foreach(wire('notices') as $notice){ if($notice instanceof NoticeError) $errors = true; } // if errors or if no created date is set it means just generated so don't redirect if ($errors || $page->created == 0) { return; } wire("session")->redirect(wire("pages")->get("template=journal")->url); } }

Update, thanks Reno, I've got it working now, not sure entirely what wasn't working before but now it's doing the job Below the code in case it helps someone at a later date <?php class BlogRedirect extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Redirects back to front end journal', 'version' => 101, 'summary' => 'Redirects back to front end journal page.', 'singular' => true, 'autoload' => true, ); } public function init() { $this->pages->addHookAfter('save', $this, 'redirect'); $this->pages->addHookAfter('trash', $this, 'redirect'); $this->pages->addHookAfter('trashed', $this, 'redirect'); } public function redirect($event){ $page = $event->arguments(0); $errors = false; // check notices for errors before redirecting foreach(wire('notices') as $notice){ if($notice instanceof NoticeError) $errors = true; } // if errors if ($errors) { return; } // if no created date is set it means just generated so don't redirect if ($page->created == 0) { return; } // set return URL $goto = wire("pages")->get("template=journal")->url; // if it's one of the chosen templates, redirect if ($page->template == "blog_post" || $page->template == "gallery_post"){ wire("session")->redirect($goto); } } }

Here is a module I use (I reduced it down to the more relevant bits). Perhaps this will help. <?php class AdminPageRedirects extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Admin Page Redirects', 'version' => 1, 'summary' => 'Redirect to after save for certain template types.', 'singular' => true, 'autoload' => true ); } protected $redirects = array( "news" => "/processwire/news/", "events" => "/processwire/events/", "venues" => "/processwire/venues/", ); public function init() { $this->pages->addHookAfter('save', $this, 'redirect'); $this->pages->addHookAfter('trashed', $this, 'redirect'); $this->pages->addHookAfter('trash', $this, 'redirect'); } public function redirect($event){ $page = $event->arguments(0); $errors = false; // check notices for errors before redirecting foreach(wire('notices') as $notice){ if($notice instanceof NoticeError) $errors = true; } if (array_key_exists("{$page->template}", $this->redirects) && !$errors){ $this->session->redirect($this->config->url->admin . $this->redirects["{$page->template}"]); } } } EDIT: Just wanted to mention that I didn't read your post all that closely, so my apologies if you are looking for something more detailed — short on time.

Pete, I reckon all what you have stated are the reasons why so many of us have gravitated to Processwire. I did a bit of scouting before we ended with Processwire. The search was for light, fast systems [coming from Joomla, WP, Drupal that was necessary] as we had enough problems building large sites with those CMS. And what I read and saw about PW here was promising. We started with one programmer who was briefed to experiment with it and within a week he was going ga ga over PW. We then took it forward to the entire team. Now, we have 10 of them working on Processwire, on various projects. PW is the choice CMS at Pigtail Pundits, replacing WordPress and the occasional Drupal project. It has given the team here new energy and fresh possibilities and that's remarkable in itself. May it continue in absolute abundance, for PW, and for the entire community behind this remarkable system.

Hi, during work on some own modules (frontend content manager, frontend users) I noticed my need of a helper module. Template2Form (working title) is a module to build a form based on fields get from a page object or a template file (tmp fake page object). During build process each field could be hooked in to modify it. Also it's possible to modifiy form, submit button and form fields via function params. It's my first (basic / dev state) module I post here... If it will be useable I have to clean up and comment the code well... template2form class <?php /** * Processwire 'template2form' module * * template2form - generate form from page / template fields * * @author pwFoo * @since 2014-07-18 * * ProcessWire 2.x * Copyright (C) 2011 by Ryan Cramer * Licensed under GNU/GPL v2, see LICENSE.TXT * * http://www.processwire.com * http://www.ryancramer.com */ class Template2Form extends WireData implements Module { /** * @var object $form generated form object */ public $form; /** * @var array $option multidimensional array with options */ private $option; /** * getModuleInfo is a module required by all modules to tell ProcessWire about them * @return array */ public static function getModuleInfo() { return array( 'title' => 'Template2Form', 'summary' => 'Generate form from template fields', 'version' => '0.0.1', ); } /** * Default module and form options * @var array $defaultOptions static mutlidimensional array with default options */ public static $defaultOptions = array( 'page' => null, 'template' => null, 'prefillFormFields' => null, 'jquery' => null, 'form' => array('method' => 'post', 'action' => '', 'id' => 'login', 'name' => 'login'), 'formSubmit' => array('id' => 'submit', 'name' => 'submit', 'value' => 'Submit'), 'formFields' => null, ); public function init() { $this->addHookAfter('Template2Form::buildField', $this, 'hookingFormField', array('priority'=>20)); } /** * Set / merge module and form options * @param array $options Array with given options * @return null */ private function setOptions (array $options = null) { if($options != null && is_array($options)) { $this->option = array_replace_recursive(self::$defaultOptions, $options); // Use template instead of page if given if ($this->option['template] !== null) { $this->option['page'] = $this->fakePage($this->option['template']); } // No template or page? Use current page... elseif ($this->option['template'] === null) { $this->option['page'] = $this->page; } if ($this->option['jquery']) { $this->modules->get('JqueryCore'); } } else { $this->option = self::$defaultOptions; } } /** * Generate the form object * @param array $options Set of optional and needed settings * @return object Generated form */ public function getForm (array $options = null) { $this->setOptions($options); $this->form = $this->buildForm (); return $this->form; } /** * Generate the form object from given fields * @return object Generated form */ private function buildForm () { $form = $this->modules->get('InputfieldForm'); $form = $this->setFormAttr($form); // Get fields to build the form $fields = $this->templates->get($this->option['page']->template)->fields; foreach ($fields as $field) { $f = $this->buildField ($field); // Get Inputfield object if ($f !== NULL) $form->append($f); // Remove NULLed fields from from... } $form->append($this->addSubmitButton()); return $form; } /** * Set form attributes and return the object * @param object $form * @return object Form with added attributes */ protected function ___setFormAttr($form) { $form->id = $this->option['form']['id']; $form->name = $this->option['form']['name']; $form->action = $this->option['form']['action']; $form->method = $this->option['form']['method']; return $form; } /** * Generate Inputfield object from given field object * @param object $field Page field object * @return object */ protected function ___buildField ($field) { return $field->getInputfield($this->option['page']); } /** * Modify the current field object by hook in after buildField function * @param object $event */ protected function ___hookingFormField ($event) { $field = $event->return; $hook = $this->option['formFields'][$field->name]; // Remove selected field... if ($hook['remove'] == true) { $event->return = NULL; } // prefill form fields from page value... elseif ($this->option['prefillFormFields'] && $event->page->get($field->name)) { $hook['set']['value'] = $event->page->get($field->name); } if (!isset($hook)) return; // nothing to do with this field... // Set form field values... elseif (is_array($hook['set'])) { foreach ($hook['set'] as $key => $value) { $field->set($key, $value); } $event->return = $field; } } /** * Build the form submit button * @return object form submit Inputfield */ protected function ___addSubmitButton() { $btn = $this->modules->get('InputfieldSubmit'); $btn->attr('id', $this->option['formSubmit']['id']); $btn->attr('name', $this->option['formSubmit']['name']); $btn->attr('value', $this->option['formSubmit']['value']); return $btn; } /** * Rendering the current form * @return string Rendered form as html code */ public function ___formRender() { return $this->form->render(); } /** * Process form data if send * @return object Processed form data */ public function ___formProcess() { $submit = $this->option['formSubmit']['id']; if(!$this->input->post->$submit) return NULL; // form NOT submitted... $processedForm = $this->form->processInput($this->input->post); // form api process form values if(!$this->form->getErrors()) return $processedForm; // form processed: OK else return false; // form send with errors } /** * Make fake page and assign needed template * @param string $tpl Template to assign * @return object Generated fake page to work with */ private function fakePage($tpl) { $fakePage = new Page(); $fakePage->template = $tpl; return $fakePage; } /** * jsConfig settings needed by wysiwyg editor * @return string Basic JavaScript config */ public function ___jsConfig () { $jsConfig = $this->config->js(); $jsConfig['debug'] = $this->config->debug; $jsConfig['urls'] = array( 'root' => $this->config->urls->root, 'admin' => $this->config->urls->admin, 'modules' => $this->config->urls->modules, 'core' => $this->config->urls->core, 'files' => $this->config->urls->files, 'templates' => $this->config->urls->templates, 'adminTemplates' => $this->config->urls->adminTemplates, ); return '<script type="text/javascript">var config = ' . json_encode($jsConfig) . '</script>'; } } Usage examples $t2f = $modules->get('Template2Form'); // Remove field 'headline' and 'body' from form $hookFormFields['headline'] = array('remove' => true); $hookFormFields['body'] = array('remove' => true); // Set / Overwrite field attributes / values like you could do with form api $hookFormFields['title'] = array('set' => array('value' => 'CustomTitle...', 'type' => 'password')); $hookFormFields['summary'] = array('set' => array('value' => 'My overwritten summary...')); // Overwrite submit button attributes (default: id, name, value) $hookFormSubmit = array('value' => 'Speichern'); /* * Build the multidemensional array * page (object) or template (string) -- to build the form from * prefillFormFields -- prefill fields (for example to build a frontend edit page * jquery -- Load JqueryCore module (during getForm() call) * form -- set form attributes / values * formFields -- array to set field values / attributes, take a look at form api examples * formSubmit -- set form submit button attributes / values */ $formOptions = array('page' => $page, 'template' => null, 'prefillFormFields' => true, 'jquery' => true 'formFields' => $hookFormFields, 'formSubmit' => $hookFormSubmit); // Generate the form and set options above $t2f->getForm($formOptions); // process form and return processed form date $process = $t2f->formProcess(); if ($process === NULL) // form not sent elseif ($process === false) // form sent, but with errors elseif ($process == true) // form sent without errors // Render form... $form = $t2f->formRender(); echo '<html><head>'; // jsConfig needed by ckeditor echo $t2f->jsConfig() . "\n"; // outpunt needed scripts for inputfield modules, ... foreach ($config->scripts as $file) { echo "<script type='text/javascript' src='$file'></script>\n"; } foreach ($config->styles as $file) { echo "<link type='text/css' href='$file' rel='stylesheet' />\n"; } echo '</head><body>'; echo $form; // output form echo '</body></html>';

Just to add to the confusion. - You can make the title field not required in template context. - You can set a template to not include global fields (advanced settings) So you could remove title for that template but still have title global.

Would love to have an indication within the admin that there was an update available. A simple icon in the footer could suffice. See the pink circle in footer of attached mockup Suggest it's only visible to users with correct permissions and reflects status of stable branch.

Worked beautifully for me. Just tried it on my new ProcessWire blog and updated it from 2.4.12 to 2.4.18. Took approx 20 seconds from download of Zip to install and upgrade. No errors. Admin and site working great. My first blog post after upgrading was about the new upgrade Module. Now, that's circular

Thanks a ton Pete for the on-page links. I'd forgotten that bit when I wrote the post. Just to clarify. We didn't build the whole site in Drupal. We had started in earnest on it. We had a few content types ready, one entire magazine was inputted, the gallery was tested and some social stuff such as Instagram and Facebook were being experimented with. We had also gone ahead with some styling on Drupal for the demo. It was after all this that we decided to switch to Processwire. Data Entry came much later, as you've guessed. Processwire is simply remarkable for sites like these. The key things for the team here were: >> Easy to understand and work with [learning curve compared to other CMS is negligible] >> Fast [no code bloat] >> Flexible for both programming and theming >> Scalable, for publisher/user driven content sites as in National Geographic Traveller India I guess that we were also lucky in that we had this wonderful project to work on, were experimenting with Processwire at that precise time, and then decided to shift to Processwire from Drupal. That's one heck of a karmic combination of events. Will check the 404 bit, thanks.

@clsource It currently provides two implementations of thread-safe counters. The first uses PHP file locks in blocking mode and stores the counters as files on local disk (under your assets folder). This allows the counters to be migrated alongside your application code if needed. The other, faster, implementation uses Redis as the counter storage engine leveraging its atomic increment and decrement functions and atomic LUA scripting. The neat thing about the Redis implementation is that the counters can be shared between multiple instances of your application (or even different applications) running on different servers. This really allows things to be distributed. It does, however, require some extra configuration work to get the Redis server set up in the first place (but that's actually pretty simple under debian and ubuntu at least.) Both implementations have mechanisms built-in to allow recovery from the deletion of (or simply forgetting to migrate) the underlying counters. I hope to have this module available for sale over the coming weekend on my first native PW shop site and I'll post more about it then.

I suppose you use the Multi language module and LanguageSupportFields. To have another language as default then English, I did a couple things to get it properly working: It depends also if you want your backend also in your default language or only the frontend. 1. Go to Setup - Languages and upload your default language files (in your case Arabic) to the default language if you want the backend also in Arabic. 2. Change the title of the default language, in your case to "Arabic". 3. Add in your case English as extra language and name it "en" 4. Go to Acces - Users - Guest and set the language to "Arabic" In this solution visitors access pages first without /ar/ for the Arabic version and with /en/ if they want the English version. As I recall you have to be carefull changing the default language. You can loose texts on pages you already added. Check also this post: https://processwire.com/talk/topic/5062-switch-default-language-possible/page-2

I have been using @font-face format recently on most of my websites (always in the CSS). Here is what's working for me with PW: p {font-family: "steagal_regularregular", Helvetica, Tahoma, sans-serif} @font-face { font-family: 'steagal_regularregular'; src: url('fonts/SteagalRegular-webfont.eot'); src: url('fonts/SteagalRegular-webfont.eot?#iefix') format('embedded-opentype'), url('fonts/SteagalRegular-webfont.woff') format('woff'), url('fonts/SteagalRegular-webfont.ttf') format('truetype'), url('fonts/SteagalRegular-webfont.svg#steagal_regularregular') format('svg'); font-weight: normal; font-style: normal; }

Couple of bits of wording jump to mind. Perhaps: Instead of "the found version....." have: "The available version is the same as your current installation" Instead of "we recommend you make another backup on your own too...." Have: "For additional safety, we recommend creating an independant database backup, for instance with PhpMyAdmin" Good tool though!

@clsource Transactions cover quite a wide area but using DB transactions isn't the only way to address the race condition for that last item or items that you have in your use-case. Here's a solution using a module I'm developing and hope to release commercially. How does this look? /** * Somewhere in your application you load the module */ $counters = $modules->get('ThreadsafeCounters'); /** * In add-to-cart logic you request a given qty of product. * You may get zero (if all taken), the number you requested (if many still left) * or some number in between (if there are too few left to fulfil entire request.) */ $reserved = $counters->reserve('product_qty_remaining', $number_requested); if (0 == $reserved) { /** * All taken - sorry! */ } else if ($reserved == $number_requested) { /** * Entire number can be fulfilled. */ } else { /** * Only a partial fill is possible. * If you don't want to handle this case in your application you either return * the $reserved qty straight away or call reserve() with the $all_or_nothing * flag set to true: $reserved = $counters->reserve(<counter_name>, $qty, true); */ } /** * If a sale falls through later (perhaps payment rejected) simply return the * number the customer ordered... */ $counters->inc('product_qty_remaining', $qty_of_product_in_order); This uses thread-safe, persistent, counters to prevent races and simplify application logic.

Ryan: this looks really cool. Haven't tried it out yet, but it should be useful, especially for my own projects I was wondering is if you'd consider adding a check for potential issues with 3rd party modules, i.e. if there's a module that hasn't been marked as compatible with the new version? As far as I know, this info isn't cached locally (at least at the moment), and not all 3rd party modules are in the modules directory, so it might get complicated, but it'd be nice to see a list of modules that could potentially cause trouble before updating. Another thing I was wondering was whether it'd be possible to somehow handle intended additions to files such as .htaccess. If one has added own caching rules or something like that, it'd be cool if the upgrade process could keep those intact. This might require a pre-defined way (or place) for specifying such things, though, so perhaps it's not feasible..

Just another alternative - you could embed the font using base64: http://sosweetcreative.com/2613/font-face-and-base64-data-uri I haven't tried this method yet, but have heard great things about it, so is on my list to try out.

Just a FYI, when I was learning about using @font-face, I ran across an old post that helped me understand some things: http://nicewebtype.com/notes/2009/10/30/how-to-use-css-font-face/ This article also had many additional links to all things @font-face and web typography.

Hehe, you might find those karmic combinations come up more and more in future - there have been many occasions here where a feature or module is released just as several of us need it in projects In the early days I likened the experience of working with ProcessWire as being "how I would have built a CMS had I the time or skills to do so" because it seemed to solve all the problems I had as a matter of course whilst not getting in the say. It's remarkably intuitive once you get going with it and it's really a load off your mind, leaving you to build a site how you want. Having possibly the most active developer I've seen at the helm is a large part of that, as is his willingness to take on board suggestions (that sort of thing is often met with skepticism or resistance elsewhere whereas it opens up a valuable and rewarding dialogue here). Plus it makes working with a CMS fun again. That's a huge part of why the community is as good as it is

No need to wait - just start using 2.5 now - lots of us are using it in production: https://github.com/ryancramerdesign/ProcessWire/tree/dev

I really need to code faster! Hehe...This was on my todo list! Saves me some time to do other stuff now (remember my recent GitHub question? ). Looking really good Ryan!

The Background Early in December 2013, the National Geographic Traveller India team at Amar Chitra Katha, called Pigtail Pundits over to help them build their website. Till then, the NGTI site was a poorly cobbled together, pale shadow of the publication in html and css, comprising, mainly content from the offline magazine articles. It was formatted too plainly, and didn’t carry the richness of imagery, gloss and character that you’d associate with anything from the National Geographic stable. The Brief NGTI had an ambitious remit for the revamped website. It will contain the offline magazine, in full, with each issue richly illustrated with some 35 odd travel stories and encrusted with glorious pictures The past issues of the magazine, some 15 of them so far, would have to be imported into the new system gradually It will carry have articles written exclusively for the web, by a separate editorial team It must have the ability for accepting photos from amateur travel enthusiasts, every day It must showcase the images from National Geographic Traveller in all its glory through on-page galleries and sliders It must have a workflow for the editorial to schedule articles into the future It must be fitted with rich tags to describe/ cross-tag the articles, the ability for browsers to comment and search ability built into it What’s more, it must come close in feel and richness to the National Geographic mother site in the US. That site incidentally, was in Beta at that time, and used some really fancy, jaw dropping scripts and effects. We were wondering as to what technology it was built on. But, there were a lot of challenges to tackle before we even reached to the front-end effects. To Drupal, or to Processwire? The Million $$ choice. We took on the challenge of the revamp. Thinking through and rationalising the different and varying content types in the magazine was our first task. We noted 13 different types. The trick was to winnow this down to just one content type that could fit all types of articles. Then, in fitting this content type into the system, we had to take a few calls. We argued that the system must have the flexibility to allow editors to embellish their articles - with drop caps, pull quotes, captions, guides and other style ornamentation that was singular to the National Geographic Traveller. In order to do this effectively, we would have pre-styled codes in the system that could be invoked using short codes as the editors saw fit. This was a whole sight better and more flexible than putting text into pre-styled boxes that would constrain the editorial. Drupal CMS was our first choice in putting this system together. We had worked with Drupal for several years now and we knew a thing or two about customising it too. The only challenge was to get a young team at Pigtail Pundits behind Drupal. The learning curve for Drupal was always daunting and that was a concern. We started work on Drupal in early January 2014. We cobbled together an internal team that would work on the project. After about a month into Drupal, we had almost everything ready for a demo to the client, save for styling. In early February, we had a rethink. We were working on some projects and testing out Processwire, internally in parallel with the NatGeo project. We found PW to be a fast, flexible, efficient system, without either the bloat and the learning curve required of Drupal. We had to take a call. Drupal, for all its goodness, still made heavy weather of its modules. Drupal optimisation alone required a lot of modules at the application level. Plus a few on the server - memcache, ably supplemented with server processing speed and memory in fair, generous helpings. But optimisation itself was just one of the many things that troubled us about Drupal. There were a heap of other modules, each adding weight and extra lumber to the ponderous system. Besides there was image heavy content. We had serious doubts as to the conditions under which the site would run well with Drupal, both immediately, and in the long run. We had to take a call. Time for a few seditious thoughts Could we now change the NGTI project to Processwire from Drupal? What would be the implications? For us, for NGTI? We had to grapple with a whole bunch of fallouts of this. How do we come clean with the client on this? Would that decision to shift hurt us? What if the client were to say no to the shift? What about getting our internal team that was already on Drupal, come to grips with Processwire? How long would that take? The reasons to shift to Processwire were clear. Speed, flexibility and scalability given the volume of content that was going to be part of the magazine and web editorial, the features we required, and the potential traffic on the NGTI site. The decision had to be made now. We decided to make an early switch to PW. And in retrospect, it was probably the best decision we took. We had to instil confidence in the client that this switch to Processwire was the right thing to do. If we relayed the news too early, it could have worked against us. We had to prove that PW was a better decision. So we went ahead and simulated all that we’d done in Drupal into Processwire without asking the client, or giving them a whiff of what we were up to. We worked in parallel on both the systems. It took us about 15 days to get everything in Drupal into PW. Mercifully for us the client was hunting for a design team that would do justice to the Nat Geo design pedigree and that took some time. Along with the fact that the new web editorial team was still being formed. We used this lull effectively to make the switch. Remarkably, our Drupal team picked up PW twithout any issues. It took them a week to grasp it and get going. That was a record of sorts as we’d folks who struggled with Drupal even after 3 months on a project, still coming to grips with techniques and modules. But PW was a cinch. The Processwire Miracle We put together the first cut of the site in Processwire. Rationalized content types for magazine articles were in One magazine issue was fed in so that we could slap on some styling Hannah code was used generously to style the content within the editor, without getting in the way of content, or trapping this into pre-styled text-area boxes. Magazine captions, guides, block-quotes, drop caps were driven by Hannah to facilitate the editorial hoopla Gallery and slider scripts were quarried for the demo The demo date was decided in early April. We showed off the system, its speed, and ease of use, live to the client. It was only after the demo that we told them that the system was not Drupal, but Processwire. They were already sold by then. The real intensity on the NGTI project however started in June 2014 when the designer Matt Daniels was brought in by NGTI. We were privy to the early designs of the Home Page, Landing Pages and Detail Pages. But were anxious as to how things would play when the entire design was complete. After all the design was not in our control. Luckily, everything went off well. There were a few challenges, and these were taken up and resolved. Javascript for the galleries, sliders had to be rewritten from scratch to conform to the design requirements Editorial came up with a list of how they wanted articles to be featured on the Home Page in blocks and we had to program this accordingly. We managed to queue the articles and then lop the old off, when the new were published Destination page required maps by default and then of city/ country being searched. This was programmed using Google APIs. Marketing came up with the need for ads - leaderboard and sidebar and we had to fit these in An Events Calendar was programmed from ground up, as per the design for Events The import of prior issues was debated, captured into excel sheets, reviewed, and reviewed some more. Scripts were written for import. Scripts were written to test the integrity of the data input before import. And everything came together in August, 2014. 6 magazine issues were imported before the launch was announced on August 14. The NGTI team went in and styled these quickly using the tools we had built for them. The final build had 20 different templates. In retrospect, we could have rationalised these too to fewer. But these came in bit by bit for the build and there was little we could do there as we couldn’t see the whole, before it arrived. The NGTI team was trained on the backend operations as part of the build itself, so by the time we had completed the site, they were up and ready to input. The project is still in beta for a few days. Optimization using just compression of CSS & JS works fine for speed. The site works like a charm now. Thanks everyone Thanks are due to Processwire and the amazing system and set of modules that are in place. Thank you Ryan Cramer. We don’t have to tell you how much we enjoy working with this system, after coming from Drupal and WordPress. Thanks to all the lovely folks on the PW forum who had answers to niggling issues we had. Key Tools, Systems used: Processwire 2.4 CMS with Foundation 4.0 framework Hannah Code for short codes in the editor for style application Event Calendar was coded ground up Form Builder was used for front end forms CK Editor, for text area editing with Image extra for description and tags ProCache - for server level caching Video Embeds and Images used field uploads Image Captions & Tags using image extra fields Scheduler, for advanced date publishing AIOM - for compressing JS and CSS for speed improvements MailChimp Integration for Newsletter Disqus Integration for Comments Integration of Facebook, Instagram, Google Maps via API Integration and customisation of Google Search Integration of DoubleClick and Adsense for advertising

Don't be discouraged by the absence of replies within the first couple of days. It sounds interesting and like something that could be useful to others as well, so keep at it.

This sort of thing is rather easy to set up using mod_rewrite too, and if there's a lot of content, that's often only sensible option. This thread might be of help to you, the problem is essentially the same. Note, though, that you should be careful with 301 redirects -- since in theory they're "permanent" browsers can cache them for a very long time. For temporary, short-term solution use 302's instead.

Hey Soma - this is definitely one of my standard modules for any new site, but was wondering if you'd consider one small enhancement that allows superusers to still see all the fields when using the hard lock option. Perhaps by disabling all form elements and removing the submit buttons? The one thing to consider is making sure that the superuser's access to the page doesn't prevent the normal user from continuing their editing of the page. As it is at the moment it is hard to help someone with an editing question when you can't see what they are editing

Soma handles documents with a special setup and a template so you could easy setup pdf's with a field "old-path" and check for this so the "old" links should work: here is his tutorial: https://processwire.com/talk/topic/4602-flexible-downloads-using-pages/ http://soma.urlich.ch/posts/flexible-downloads-using-pages/ this is really great! I use it on a page with some pdf's to count downloads - so your file could have a different name/url and adding an "old-url" field should be no problem. And since a pdf-download is a page you can redirect it via your normal methode, too without need of additional fields and changing the PDF!! Hope this helps - mr-fan

font-family: 'Open Sans', sans-serif; Remove "sans-serif" part. Font substitutions do not belong to the @font-face declarations.

Hi Horst thanks for your reply but I think it is "pages" i get a system error when i try with "page".

setting is like reems writes under >access>users>guest (=visitors) change the default language on this the default language under >admin>setup>languages couln't changed....your right.

Have you tried to declare @font-face rules before any other css rules?

When I took those screenshots, I was basically left with no more sites to upgrade.

@Ottogal, in this particular case, Ryan upgraded with a version that matched his current version

Hey thanks I've definitely spent some time googlin but that final link held the answer. I've not seen that part of the cheatsheet, thanks for the link ! K so I am going to use setLimit('x') perfect! So happy.

This seems a bit circular...

didn't know that. Updated the version number. Thx!

I'm in a hurry: https://www.google.com/search?q=site:processwire.com+pagination https://www.google.com/search?q=site:processwire.com%2Ftalk+pagination https://processwire.com/api/modules/markup-pager-nav/ (limit) ...

I was seeing the same thing. I went in to the two .module files and changed the version numbers from "010" to "10" and refreshed the modules list and voila. Not sure if that really was the issue, but it worked for me. Ryan mentions this: "The module version number shouldn't have preceding zeros, as this starts PHP thinking it's an octal number or something else (I don't recall). So version number should be 10 rather than 010." PS The module files were actually already the correct version - just the reporting that was off.

unrelated: Jan I love your profile photo - every time I see it I smile.

I’d say give the current dev version a whirl and update when 2.5 is released. Check out the dev branch thread in the announcements forum. A bunch of people are already running dev on production sites, as it seems. https://github.com/ryancramerdesign/ProcessWire/tree/dev https://processwire.com/talk/topic/3768-processwire-dev-branch/page-13 edit: eh, beaten. Copy and paste is a bit tedious on mobile

Just tried again without VPN and it downloaded in 12 seconds and no problem unzipping this time!

Thanks for sharing a really beautiful site with us! I like this project for so many reasons, but the main one is it is a perfect showcase of what you can do in ProcessWire with a little knowledge and time. 15 days to convert everything from Drupal to ProcessWire? Wow, that's quite something for this site. Did you have all the content already in Drupal so it was a case of moving everything over? Or was it more 15 days to get ProcessWire set up for all of the various content types and data entry came later? I know you can build things very fast in ProcessWire and with a dedicated team of people working on it it must be an even faster experience Again, a perfect example to anyone wondering what relatively-unknown system can do - certainly another site I will be pointing people to to allay any fears around whether ProcessWire is capable of delivering complex sites. Hope you don't mind, but I linked to the site a couple of times in your original post - once when you first mention the revamped site and also made the screenshot clickable to the site, just so folks don't miss it. EDIT: When you get to the 404 page, it says "NULL" in the top-left corner. I saw it due to a typo, so no broken links or anything like that

Thanks Ryan! That's very appreciated. I value your work on PW a lot and think you really deserve the money you put into modules. Good to know I'm not crossing any line there!

Pierre-Luc it's nice of you to ask, but also unnecessary. That's always your choice if you want to release something you've created. There aren't any restrictions on what can be released as free modules (so long as they don't use code from commercial ones).

+1 for drafts. That's something i consider essential (and the only thing that im REALLY missing in pw) for every cms (and I can't think of one that hasn't got this feature apart from pw)! Almost EVERY of our customers asked if they can preview their edits or schedule changes to an exisiting site to be published at some later point.

Getting there Will try to finish a first version tomorrow. Basically same function as PageTable but with the option to render the parts for a better visual interface for editors.

Hi Mikkelsen, Look at this TravelinLuxury It's presented here in the showcase as well. I just finished this travelsite using Processwire, including the FormBuilder module, Google Maps and lots of other functionality. If I could be of any assistance, just let me know.

Started a new module for creating <tables> from repeater fields. Feel free to grab it from github, do with it what you want. It only works for simple text based fields inside a repeater. To use it: $table = $modules->get("RepeaterTable"); // initialize $table->thead = true; // (bool) true/false, default = true, will render <th> $table->indent = 3; // (mixed) false/int, where int is the level of indentation, default: false $table = $table->render($page->repeater); // repeaterfield called repeater <!-- output --> <table class="table-repeater"> <thead> <tr> <th class="col-1">Fieldlabel field 1</th> <th class="col-2">Fieldlabel field 2</th> <th class="col-3">Fieldlabel field 3</th> </tr> </thead> <tbody> <tr class="row-1"> <td class="col-1">data for field 1, first repeater item</td> <td class="col-2">data for field 2, first repeater item</td> <td class="col-3">data for field 3, first repeater item</td> </tr> <tr class="row-2"> <td class="col-1">data for field 1, second repeater item</td> <td class="col-2">data for field 2, second repeater item</td> <td class="col-3">data for field 3, second repeater item</td> </tr> </tbody> </table> For the HTML purist, I have added source code indentation where you can set how many tabs you wish to append before each element. Please let me know if I should add this to the modules directory ? Does someone have a good name for this ?

You can add that flexibility with a little logic in your templates. Say you add 2 checkboxes, Display Album & Render Children. Then on the template you check if "Display Album" is true and count the images. If there are to less or none just display a photo or do nothing. When there are more then x items display an album. Same goes for child pages. If you want it in between your page body, you can use php's str_replace. But I think the easiest way right now is using Hanna code A simple Album/Foto script for-example: modify it for your needs !HannaCode:album:eyJuYW1lIjoiYWxidW0iLCJ0eXBlIjoiNiIsImNvZGUiOiJcLypoY19hdHRyXG50YWc9XCJcIlxuaGNfYXR0cipcL1xuaWYoc3RybGVuKCR0YWcpKSB7XHJcblx0JGltYWdlcyA9ICRwYWdlLT5pbWFnZXMtPmZpbmRUYWcoJHRhZyk7XHJcblx0JGNvdW50ID0gY291bnQoJGltYWdlcyk7XHJcblx0XC9cLyBzaG93IHBob3Rvc1xyXG5cdGlmKCRjb3VudCA8IDMgJiYgJGNvdW50ICE9IDApIHtcclxuXHRcdGZvcmVhY2goJGltYWdlcyBhcyAkaW1hZ2UpIHtcclxuXHRcdFxyXG5cdFx0XHQkdGh1bWIgPSAkaW1hZ2UtPndpZHRoKDYwMCk7XHJcblx0XHRcclxuXHRcdFx0aWYoJGltYWdlLT53aWR0aCgpID4gNDAwKSB7XHJcblxyXG5cdFx0XHRcdGVjaG8gXCI8ZGl2IGNsYXNzPSdpbWFnZSBwaG90byc+XFxuXCI7XHJcblx0XHRcdFx0ZWNobyBcIlxcdDxhIGhyZWY9J3skaW1hZ2UtPnVybH0nIGRhdGEtZnJlc2NvLWNhcHRpb249J3skaW1hZ2UtPmRlc2NyaXB0aW9ufScgZGF0YS1mcmVzY28tZ3JvdXA9J3skcGFnZS0+bmFtZX0nPlxcblwiO1xyXG5cdFx0XHRcdGVjaG8gXCJcXHRcXHQ8aW1nIHNyYz0neyR0aHVtYi0+dXJsfScgXC8+XFxuXCI7XHJcblx0XHRcdFx0ZWNobyBcIlxcdDxcL2E+XFxuXCI7XHJcblx0XHRcdFx0ZWNobyBcIjxcL2Rpdj5cXG5cIjtcclxuXHRcdFx0fSBlbHNlIHtcclxuXHRcdFx0XHRlY2hvIFwiPGltZyBzcmM9J3skdGh1bWItPnVybH0nIGRlc2NyaXB0aW9uPSd7JGltYWdlLT5kZXNjcmlwdGlvbn0nIFwvPlwiO1xyXG5cdFx0XHR9XHJcblx0XHR9XHJcblx0XHRcL1wvIHNob3cgYWxidW1cclxuXHR9IGVsc2UgaWYoJGNvdW50ID49IDMpIHtcclxuXHRcdGVjaG8gXCI8dWwgY2xhc3M9J3RocmVlX3VwIHRpbGVzJz5cXG5cIjtcclxuXHRcdGZvcmVhY2goJGltYWdlcyBhcyAkaW1hZ2UpIHtcclxuXHRcdFx0JHRodW1iID0gJGltYWdlLT5zaXplKDIwMCwyMDApO1xyXG5cdFx0XHRlY2hvIFwiXFx0PGxpPlxcblwiO1xyXG5cdFx0XHRpZigkaW1hZ2UtPndpZHRoKCkgPiA0MDApIHtcclxuXHJcblx0XHRcdFx0ZWNobyBcIlxcdFxcdDxkaXYgY2xhc3M9J2ltYWdlIHBob3RvJz5cXHJcXG5cIjtcclxuXHRcdFx0XHRlY2hvIFwiXFx0XFx0XFx0PGEgaHJlZj0neyRpbWFnZS0+dXJsfScgZGF0YS1mcmVzY28tY2FwdGlvbj0neyRpbWFnZS0+ZGVzY3JpcHRpb259JyBkYXRhLWZyZXNjby1ncm91cD0neyRwYWdlLT5uYW1lfSc+XFxuXCI7XHJcblx0XHRcdFx0ZWNobyBcIlxcdFxcdFxcdFxcdDxpbWcgc3JjPSd7JHRodW1iLT51cmx9JyBkZXNjcmlwdGlvbj0nXCIgLiAkaW1hZ2UtPmRlc2NyaXB0aW9uIC4gXCInIFwvPlxcblwiO1xyXG5cdFx0XHRcdGVjaG8gXCJcXHRcXHRcXHQ8XC9hPlxcblwiO1xyXG5cdFx0XHRcdGVjaG8gXCJcXHRcXHQ8XC9kaXY+XFxuXCI7XHJcblx0XHRcdH0gZWxzZSB7XHJcblx0XHRcdFx0ZWNobyBcIjxpbWcgc3JjPSd7JHRodW1iLT51cmx9JyBkZXNjcmlwdGlvbj0neyRpbWFnZS0+ZGVzY3JpcHRpb259JyBcLz5cXG5cIjtcclxuXHRcdFx0fVxyXG5cdFx0XHRlY2hvIFwiXFx0PFwvbGk+XFxuXCI7XHJcblx0XHR9XHJcblx0XHRlY2hvIFwiPFwvdWw+XFxuXFxuXCI7XHJcblx0fVxyXG59In0=/!HannaCode