Leaderboard

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

Hi guys. Just wanted to properly say "hi" and thank everyone for all the help lately. I'd been posting as "sparrow" for many months while I got started and many of the regulars here have been a great help. I'm an independent web designer from Dublin, Ireland, and my primary CMS is MODX. A while ago I decided that 3 CMS would be a good number to settle on and I began to evaluate Craft and PW. What attracted me to PW specifically has been all the good stuff I'm sure you already appreciate but in particular, I really like: PW fields and especially how powerful the Profields set are Lister (not released yet) Image management (native and CropImage etc. Image control is brilliant in PW) Fields control (allowing me to specify exactly which field(s) to display per template) How friendly the community is How communicative Ryan is re. the product and the fact that there is a roadmap and that roadmap is largely followed and updated The array of great Modules available etc etc. But basically, PW has been impossible to ignore with the recent adittions of Profields and Lister. I'm very much at the beginnings of my PW journey so to be balanced, these are the areas that I've found challenging: Speed. I find *just* having a tree slows my editing down a lot. Would love to see a tree on the left and the page edit on the right. Obviously, I'm coming to this from a MODX perspective Right-click Again, probably baggage from MODX but it's very useful to be able to right-click a page and duplicate, delete, move, hide from menu, quick-edit etc etc. I can't do this on PW. But mayeb there's not such a need. User control The user control and permissions look very basic. I'm used to much more fine grained control over which elements of the admin a client can see Manager appearance When I first installed PW I found the box-iness and colors a bit hard to settle into. Some of that may have just been TinyMCE which I replaced and I believe made a huge difference. I know there are lots of themes available so that's not an issue now but was definitely a "first impressions" thing. PHP That's not PWs fault. I've gotten used to working with tags so being pushed into a bit more PHP has been a challenge. I'm enjoying it though and feel my skills are slowly but surely coming on. So that's my 2cent. Thanks again for all the help so far and it's great to be part of yet another very friendly CMS community. On a side note, I have started a mini blog based on PW, Craft and MODX as I think they really are 3 of the best CMS available. Will update soon when I have a little more content.

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

Tanks to all of you so far. It's actually a really amazing trip already: a lot of nice people in my hostel I got to know (espacially this lovely british girl ) and an amazing city! Will post more when I'm back

destinations UNLIMITED This site is a conversion from an old Joomla site that is far better suited to processwire due to the 100s of facts and figures about the destinations. Many of the facts from each of the destinations help to form other content such as blurbs on the video content hopefully adding quality content for google to index. It's also got a growing number of features for registered users such as being able to add personal comments to destinations which collate into a personal notebook. Hope you enjoy having a look around. Although the site is now live, I don't think it will ever be finished! ..not to forget a thank you to everyone who has helped me with the project along the way!

Thank you all. If you have something else on your "wishlist" for development let us know. We spent the last week working on a super boring SAP shop for a university project so progress slowed down a little bit. However, I've made a new video to show the latest features we've been working on. Beside the new "Create site" page and the workflow for new users, we build backend features like the version change and a backup system. The service always has the latest ProcessWire files from github and it's possible to schedule sites for deletion now. Some bugs are still open and the Help page was just started. Our plan is to launch the service to the public in the next week.

There are many ways of finding out whether site runs on pw or not. That is just one of those. Pw doesn't try to hide it's existence. Isit.pw is done to help maintaining the sites section on this site easier. So intentionally hiding your site just for this tool might make your approval process longer

If you'd choose "Single page (Page) or empty page (NullPage) when none selected" in your pagereference field, then the error wouldn't happen. However, maybe you should modify your snippet to check if there is a page selected before outputting the url

Hey everybody, Many of us know about isit.pw, the web site that checks if you are running PW. I thought I should find out how it knows whether a web site is ProcessWire-powered. Turns out, it sends a "GET /?it=/trash/ HTTP/1.0" request, and if the response is 200, then PW it is. Next thing I did was to go to admin templates and change the default behavior such that ProcessWire would through back a 404 instead of offering to log in. Now, isit.pw does not like me for "not running" ProcessWire. However, I liked the method isit.pw uses. It can be handy if you want to run a quick check like this: http://<...>/<some_page_name/?it=/ If you get the Home page, it means you've hit a ProcessWire-powered web site. Have a good Friday and a nice week-end

Hey Zahari, In a bit of a rush, but PHP's strstr might be what you are looking for. Not sure that you really need a Hanna Code in this situation. Just parse the content of the field in your template. $introtext = strstr($page->body, '[[readmore]]', true); Then when you echo out the body on the full version, just: echo str_replace("[[readmore]]", "", $page->body); Hope that helps to get you started. I am sure there are lots of other ways to approach this. I usually go with automatic truncation because editors usually forget to add things like a [[readmore]] tag.

done. https://github.com/ryancramerdesign/ProcessWire/issues/641

It's kinda hard without knowing how that site exactly works, but i think almost any site can benefit from ProCache. You can enable cache on pages (templates) where it makes sense and leave out the ones where it does not make sense. Also, you can define what happens on page saves etc. http://processwire.com/api/modules/procache/ I think it will enhance the performance of almost any site, in varying degrees.

u.shloud rlease u module soon.i release my astral datetime.menstrul cycle fieldtype and .inputfeld

I think we need an option "don't ever display children here" as a template setting. At least for editors. Even I am a bit confused when I accidentally open a folder in the tree where all this data crap is in

I think this will fix it: $newsposts = wire("pages")->find("template=254_news_article,limit=5,sort=-published_date,start=0"); Note the addition of start=0 - this is to override the insertion of start from the pagination code.

PageTableExtended Download here: http://modules.processwire.com/modules/fieldtype-page-table-extended/ Extends the Processwire PageTable field for rendering table row layouts. This is great for editors, because they actually see at a glance what the table rows consist of. What it does Turns the Processwire Fieldtype "Page Table" from this: into something like this (sorting capabilities of course still functional): See it in action: Requirements FieldtypePageTable installed (part of the core since Processwire 2.4.10.) Templates used for PageTable need a file associated (otherwise nothing gets rendered) This render method is meant for sites where the PageTable templates only render part of the layout, not complete websites. But you also can define what will be rendered (see below). Options Render Layout instead of table rows Check this for seeing the rows rendered. You can easily turn off the complete functionality by unchecking this. Path to Stylesheet Since the parts are unstyled by default, it is a good idea to define styles for them. All rendered templates are encapsulated in a div with the class "renderedLayout" so you can style them with: div.renderedLayout h2{ color: green; } The path is to be set relative to your templates' folder. Reset Admin CSS Since the parts are rendered inside the Admin, common styles of the Admin Interface apply also to your layout parts. This is not a bad thing, because especially text styles are well integrated in your admin's theme. But if you like to override the admin styles in your table rows completely (more or less), just check this box. Don't forget to define a custom CSS then! Advanced Since this module is meant for parts of your layout you already have defined for your frontend templates, it is a good idea to use a preprocessor like Stylus, Sass or Less for building the custom CSS file. Just outsource your layout part definitions in an extra file, compile that in a separete CSS file and use this as custom CSS for this module. Since your CSS is should be built in a modular way, this works pretty well ;-) Will write a tutorial with a use case once finished testing. Notes: Github: https://github.com/MadeMyDay/PageTableExtended If you want to get rid of the unnecessary step for entering a title before editing the page, just set the "autoformat" value as suggested in the PageTable settings. If you don't want to use a title field at all, see this post from Soma Will put it in the module repository once finished testing. Please test it and give feedback. I haven't used GitHub for a long time, please check if everything is in place and if this will work with the modules manager and the new core module installer once added to the repository. Have fun Module is in the repository now: http://modules.processwire.com/modules/fieldtype-page-table-extended/ Please use GitHub for instructions, I made some additions there.

As some of you might have noticed recently there has been a large "Frontend Performance Talks Offensive" (not only) by Google Engineers. Here are some high quality (regarding content) Videos which i enjoyed very much and thought you also might be interested in. A Rendering Performance Guide for Developers by Paul Lewis: Performance Tooling by Paul Irish Your browser is talking behind your back by Jake Archibald Gone In 60fps – Making A Site Jank-Free by Addy Osmani http://addyosmani.com/blog/making-a-site-jank-free/ Any suggestions for more interesting performance related stuff are welcome!

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!

(Javascript) Memory Management Masterclass with Addy OsmaniEfficient JavaScript webapps need to be fluid and fast. Any app with significant user interaction needs to consider how to effectively keep memory usage down because if too much is consumed, a page might be killed, forcing the user to reload it and cry in a corner. Automatic garbage collection isn't a substitute for effective memory management, especially in large, long-running web apps. In this talk we'll walk through how to master the Chrome DevTools for effective memory management. Learn how to tackle performance issues like memory leaks, frequent garbage collection pauses, and overall memory bloat that can really drag you down.

As processwire.com uses Typekit, the situation: http://status.typekit.com/ Well it seems the problem in Australia has been resolved. In Spain the issue could be related to the ISP.

Plz file an issue on github. Better for Ryan to spot soon..

I've read that jQuery on the google cdn is the most used & cached file on the net. So it's not rare that the guest already has that version in browser cache. For jQuery as it is relative big it makes sense to use that cdn. I do love the HTML5 boilerplate trick to get that version. So far I understand, there is a max of simultaneous downloads of assets from the same subdomain. If you could spread the load to more locations, even if it is an other subdomain, more simultaneous downloads are allowed. I have never tested this.

I think the problem with that approach is that you won't get the local caching benefit of using the Google CDN, because no other visitors to your site will have those files cached from the PW git repo. I would suggest either using a well known CDN (eg google), or use the local version from your PW install - afterall, those files are already on your server. I would however use the excellent AIOM module on them. I am no expert in this area, but hope that helps.

One little point: There's a lot of `console.log` going on. Somehow there's in my mind that that could break processing of javascript in old versions of IE. (Maybe i'm wrong) Never the less I want to mention it

One little point: There's a lot of `console.log` going on. Somehow there's in my mind that that could break processing of javascript in old versions of IE. (Maybe i'm wrong) Never the less I want to mention it Posted this to the wrong post. Hell yeah, I like tabs in browsers

The first one, since the second one sounds redundant and users are pages anyway. And you could use roles to control viewing and editing. Detecting a user's role or create new ones via a module is way easier than to manage a somewhat parallel structure.

This works for me. This replaces all the existing buttons and adds a new one called "custom". Is that what you are looking for? public function init () { parent::init(); wire()->addHookAfter("ProcessPageListRender::getPageActions", function($event) { // anonymous function $event->replace = true; $new_action = array( 'cn' => 'custom', 'name' => 'Custom', 'url' => '/my/path' ); $event->return = $new_action; }); }

Oh! more translated lines! Thanks a lot!

The site is not so fast from where I and Google PageSpeed servers are. I think it is worth spending time to make it load a bit quicker. The sidebar overlaps main content in around 800px wide. Not sure if there are many devices with that screen width, but still... Looks really good. Exellent job, ChiefPundit!

Welcome ChiefPundit, What a nice read while drinkin' coffee & a beautifull site !

The last update was 20 files, this has 126 fully translated. Updated Sept/2014: ProcessWire 2.4.15. --> 126 files --> 100% translated. Files translated: https://github.com/LuisSantiago/Processwire-Spanish/tree/master/Processwire-master-Spanish%20(100%25%20Translated)

Thanks a lot to everybody! You all was really helpful. I think in one page I didn't set the pagereference and this cause the error (still not sure). But now thanks to your advice works perfectly. Great forum and PW rocks! Edit: Previously I setted the Page as "Single page (Page) or boolean false when none selected" instead of "Single page (Page) or empty page (NullPage) when none selected" and now works also if a page reference is blank

Hi sharpenator, Looks like this module from Soma could help you out: http://modules.processwire.com/modules/page-list-image-label/ You could use it to render the icon image of your "format pages" Cheers

This sounds strange. What do you get when outputting var_dump($menu->pagereference);die(); Should be a Page object with lots of information... what does it say in your case?

Maybe there is a page sneaked up in you menu's that hasn't the right template.

PW 2.5 (https://github.com/ryancramerdesign/ProcessWire/tree/dev) will be released within the next couple of weeks. Many of us have been using the dev version in production with no problems. It always pays to test though, so if you don't have a test server setup, rename your existing wire folder to wire-old or similar so you can revert quickly should there be any problems.

If it's a multiple select page field, then you either need to convert it to single select, or grab the first one: $menu->pagereference->first()->url;

If checking physically in GitHub, look in the file /wire/core/ProcessWire.php on this line and the next two. Not sure if it is in other places too...

It depends on what you have. If you have the specialty as a string, you can select for the page’s title field like so: $pages->find('template=physician, specialty.title={$search}'); If you know the specialty’s page-id or path, that should work as well. For example on a specialty page, you would want to list all physicians that have that specialty: $pages->find('template=physician, specialty={$page->id}');

You can also remove the fields using the API.... Backup your site first, please! This was written in a function context so feel free to change it and use in a template file context. You could also wrap the code in a conditional if $user->isSuperuser... Changed and done... if ($user->isSuperuser()) { //first remove the fields from 'user' template before deleting them. $t = $templates->get('user'); $fg = $t->fieldgroup; $fg->remove($fields->get('your_field')); $fg->save(); //delete the fields $f = $fields->get('your_field'); $fields->delete($f); }

Does anything from this post from Ryan help: https://processwire.com/talk/topic/4011-cannot-login-to-admin-area/?p=39870 In particular: disable the "session fingerprinting" option in your /site/config.php and change the default session name from 'wire' to whatever PHP's default is: $config->sessionName = session_name();

Where there with my class before school graduation. If you're into arts the stuff gaudi build all over barcelona is worth a visit as well as the Picasso museum. From the "Castell de Montjuïc" you can have a great look all over barcelona and the harbour.

@ryan. Not a lot of demand? What planet do you live Well, everytime this comes up it get's many likes. My post just got 7 likes. I and many others are waiting for versioning/drafts since a long time. Thing is that it was on the roadmap all the time, so many of users are not asking for it again and again cause it's already.. well "ordered". I agree that it might not be always needed, and I see that this is not a quick implementation (I wouldn't know how in PW this should be designed). Maybe PW just isn't designed and capable for such a feature. And also it can lead to confusion if not implemented right. And all that comes with it, all correct. But I think it's a feature many are waiting for.

Never been there before. I think you should try some good homebrewed beers

You can go for Language-Alternate fields.

Just for the record, since it's closely related to this thread, there's a pull request in GitHub about SQLite support (opened back in May). There are quite a few changes and most likely it isn't in sync with current dev branch (it's based on the master branch), but still works as a nice proof of concept for SQLite support. If any SQLite user here is able to get that one running and could run a few tests to see how well it behaves (the questions Ryan asked in his comment to the PR, like how well selectors work etc.) it would be interesting to hear.

You would need cache field per template. If your "parent" template and PageTable template has same searchable fields, then you would be good with one cache field. Although I am not sure if one field would go in either way (if it just skips the fields that are not interested template then one field works). Anyway, both of your templates need cache field attached, selector could be something like "(cachefield%=$q), (PageTable.cachefield%=$q)". Parenthesis make it Or selector, so it would be enough either of selectors match, no need for both to match.

Just use the wonderful CropImage module. Say, you have a 300x300 image in your template. Define one 300x300 called "thumb" and one 600x600 crop called "thumb2x". Now you can use the picture polyfill like this: <picture> <img srcset="<?= $page->myimage->eq(0)->getThumb('thumb') ?>, <?= $page->eq(0)->myimage->getThumb('thumb2x') ?>, 2x" alt="<?= $page->myimage->eq(0)->description ?>"> </picture> Adding additional breakpoints with <source> is also possible (from the picturefill docs): <picture> <!--[if IE 9]><video style="display: none;"><![endif]--> <source srcset="examples/images/large.jpg, examples/images/extralarge.jpg 2x" media="(min-width: 800px)"> <source srcset="examples/images/small.jpg, examples/images/medium.jpg 2x"> <!--[if IE 9]></video><![endif]--> <img srcset="examples/images/small.jpg, examples/images/medium.jpg 2x" alt="A giant stone face at The Bayon temple in Angkor Thom, Cambodia"> </picture> So you can also do some art direction where you output not only different sizes but also different formats (for example 2:1 on mobile, 1:1 on desktop etc)

To build on top of Ryan's response, redirecting is not just sensible to do on login, but whenever you have forms. The wikipedia page on the Post/Redirect/Get pattern explains it much better than what I can - it's definitely worth the read

Create an account on transifex and I add you into a project. It seems to be a very nice tool for doing translations in collaboration. Translations are easiest way for many people to "give back", and current way isn't very easy to get started. In github model you don't even see the original strings, which makes it clumsy. I think that tool like Transifex would lower the barrier to contribute and manage translations.