Leaderboard

http://www.tamperemusicfestivals.fi/jazz/ The four-day jazz festival starts today. There will be a lot of traffic on the website, but I'm sure everything will run smoothly since ProCache makes the site run very lightweight and fast. In previous years this website has been running on WordPress or MODX. This year we switched to ProcessWire, and it has been a huge improvement. Everything on the site is fully editable, which makes the client very satisfied. Also, PW has revolutionized my workflow as well. I have quite the same feeling as when I switched from Windows to OS X : ) Logo is designed by the artistic director of the festival, everything else by me.

In this tutorial we make a simple function that becomes part of every PageArray. Once hooked to the PageArray class, you can call this function from anything returned from $pages->find(), $page->children(), or your own page references like $page->categories from the blog profile, etc. It essentially becomes a new function available to you from any PageArray anywhere in your site. First, lets look at what convenience the hook function adds and how we might use it. We'll call the hook function "renderLinks", but you could of course call it whatever you wanted. We call that renderLinks() function from any PageArray, and it returns a string representing that PageArray as a list of links. By default, this renderLinks() functions separates each page with a comma, and outputs the page's title as the anchor text. We can change that to be anything by specifying arguments to the call. The first argument is the delimiter, which defaults to a comma ", " if not specified. The second argument is the name of the field to output, which defaults to "title" if not specified. Next are 3 examples of how this renderLinks hook function could be used. Usage Examples: Example 1: render a comma-separated list of links: echo $pages->find("parent=/")->renderLinks(); Output: <a href='/about/'>About Us</a>, <a href='/contact/'>Contact Us</a>, <a href='/site-map/'>Site Map</a> Example 2: render a <ul> of $categories links: <ul> <li> <?php echo $page->categories->renderLinks('</li><li>', 'title'); ?> </li> </ul> Output: <ul> <li><a href='/categories/category1/'>Category 1</a></li> <li><a href='/categories/category2/'>Category 2</a></li> <li><a href='/categories/category3/'>Category 3</a></li> </ul> Example 3: render a breadcrumb trail: <p class='breadcrumbs'> <?= $page->parents->renderLinks(' / ') ?> </p> Output: <p class='breadcrumbs'> <a href='/parent1/'>Parent 1</a> / <a href='/parent1/parent2/'>Parent 2</a> / <a href='/parent1/parent2/parent3/'>Parent 3</a> </p> Those examples above show some of the potential of how you might use such a function. Next is the hook function itself. In order to be available to all templates in your site, it needs to be defined somewhere consistent that is always loaded... Where to put the hook function: If using the basic profile (that comes with ProcessWire) you could put the hook function at the top of your /site/templates/head.inc file. If using the Foundation or Skyscrapers profile, you could put the hook function in your /site/templates/_init.php file. This is the method that I use. If using something else, you could create a /site/templates/_init.php file with your hook function(s) in it, and then edit your /site/config.php to point to it with the $config->prependTemplateFile = '_init.php'; so that it is automatically loaded on every request. Note that the name "_init.php" is not required, you can name it whatever you want. You could put it in an autoload module... but that might be overkill here. The actual hook function: wire()->addHook("PageArray::renderLinks", function(HookEvent $event) { // first argument is the delimiter - what separates each link (default=comma) $delimiter = $event->arguments(0); if(empty($delimiter)) $delimiter = ", "; // second argument is the property to render from each $page (default=title) $property = $event->arguments(1); if(empty($property)) $property = "title"; // $out contains the output this function returns $out = ''; // loop through each item in the PageArray and render the links foreach($event->object as $page) { $value = $page->get($property); if(!strlen($value)) continue; // skip empty values if(strlen($out)) $out .= $delimiter; if($page->viewable()) { // if page is viewable, make it a link $out .= "<a href='$page->url'>$value</a>"; } else { // if page is not viewable, just display the value $out .= $value; } } // populate the return value $event->return = $out; }); If using PHP before 5.3, or using an older version of ProcessWire, you'll need to change the first line to this (below). This syntax also works with newer versions as well, but it's not as pretty as the new syntax. wire()->addHook("PageArray::renderLinks", null, 'hookRenderLinks'); function hookRenderLinks(HookEvent $event) {

Greetings, This is a discussion I am glad to get into... I'd want to know more details about what the client needs and expects to accomplish, because that would definitely help make stronger arguments against Joomla. But up front, my main arguments are... Joomla does not support custom fields in its core. The only way to be able to have custom fields in Joomla is to add what is known as a "CCK" (Content Construction Kit), and that essentially grafts what I call a sub-CMS onto the main CMS. Without a CCK, you are stuck with the basic fields that Joomla assumes you will use for all your pages ("articles"). It is extremely tricky to implement what we think of as routine JS and PHP elements in Joomla sites. You cannot properly work directly inside your page code, as everything in Joomla is done inside "module positions" for your pages. Speaking of templates, the templating structure of Joomla is extremely limiting. Everything in your site must be placed inside those "module positions," you must define everything that goes into those module positions using a convoluted back-end, and your templates inherit all sorts of core Joomla styling and layout assumptions. In other words, you cannot simply create various layouts and name them according to specific content types. Joomla core makes numerous assumptions about how things should look and behave. If you want to change how a blog list looks, for example, you must hack core settings of either your core Joomla install or your templates. If you simply want to say "See Full Story..." instead of "Read More..." at the end of your intro pages, you have to hack the core code. Joomla makes it extremely difficult to manipulate URLs in any kind of creative fashion. Because it assumes you must always insert an "article ID" into your URLs, you cannot go very far with dynamic pages because you cannot know the ID of your "articles" before they are created. The core installation of Joomla has a convoluted directory structure: 15 main directories and an arrangement of sub-directories that are a major challenge to follow. Often, sub-directories are literally repeated and material of the same type (such as plugins) can end up in several different directories. This is because Joomla is designed to be built completely in the GUI, which gets us back to the problem described above in #2. These are just a few of the problems that plagued my work with Joomla. But again, the real power comes when the client says, "I want this..." and you can show how much better and easier it is to do it in ProcessWire. Can you follow up with some of the specific requirements of the client? Then I can give you more particular arguments. Thanks, Matthew EDIT: onjegolders: yes, indeed... Looking back, I think I have actually posted a few "Joomla rants" here in the ProcessWire forums: http://processwire.com/talk/topic/2129-justifying-diy-coding-vs-installing-modules/?p=20438 http://processwire.com/talk/topic/4143-wordpress-dominates-19-of-the-web/?p=40964 http://processwire.com/talk/topic/3952-reservations-for-hotel-rooms-and-restaurant/?p=38742

Just. Don't. Use. It. Seriously: I worked with Joomla exclusively a while ago (around 2004/2005) and the whole concept hasn't changed imho. The main problem is: It is by no means a flexible content management system, it is more a portal system. Let me explain what I mean: Let's say you have a large scale company with 1000 employees. All of those employess have a name, an email, a title and a linked department. You want to display one/several employees on each page in a kind of sidebar. The PW way: - Create a employees template - Add desired fields - Create page field in your other templates for selecting employees - You are then totally free to select employees in your template and you are able to output what you like (HTML, CSS). - You also have the possibility to use that information somewhere else because these are just usual PW fields. - An editor selects the employee(s) where it is needed: While editing the page The Joomla way: - Look if a module exists for that does this job for you (perhaps there is one, but probably not). - even if there is one you have to add your employees in some kind of extra database, where you are tied to the output of the module (not necessarily, perhaps the script kid lets you customize it). - But the biggest problem: Your editor will not be able to select the employees where it is needed. They have to go the modules section in the backend, have to find the module, have to identify the page they want to edit and then have the possibility to select an employee. This is a ridiculous workflow, image you have not only an employee to select but also header images, other side information and so on. The rest of Joomla can be summed up: - Bloated - poor security - inflexible - poor templating Joomla totally is okay for smaller groups, clubs or where ever no technical experience is needed and where the requirements are low. Everyone can set up a site really fast and choose from a lot of plugins (mostly poorly coded though). But when it comes to comfort, flexibility for editors... it is just poor.

I think it would be useful to get Matthew on this discussion. I will PM him, just so he knows

Then you haven't studied the HelloWorld.module that comes as example? Hmm... it was the first thing I checked out when starting looking into modules and there's all examples also adding properties and methods. It's what definately blew my mind and made me stay with PW after all Edit: I don't mean to put you down or something was just wondering and I'm glad you found out now!

The answer is relatively simple and there would be different ways but best would be to: In a autoload module (HelloWorld.module) add the hook to ready() where the page being rendered is already set in $this->page So this would only add property to basic-page templates: public function ready(){ if($this->page->template == "basic-page"){ $this->page->addHookProperty('hello', $this, 'helloHook'); } } public function helloHook(HookEvent $event){ $event->return = "Hello World"; } After all I'm not sure this would make a lot of difference to just add it pages globally. But I could see this being useful for certain situations.

You can add hooks in the template files themselves. Here is a great post about hooks by teppo: http://www.flamingruby.com/blog/using-hooks-to-alter-default-behavior-of-processwire/

Here's a cool approach from WillyC: http://processwire.com/talk/topic/1799-routes-and-rewriting-urls/?p=16708 Or you could add a line to your htaccess file (as devcow shows), or if this is a change from what the parent page used to be called this module would do the trick, but you need to have it installed before the change in the name of the page, http://modules.processwire.com/modules/page-path-history/ I guess you could change the name back, install the module, and then change the name again. It's an awesome module to have installed right from the start of development! EDIT: If you go with the htaccess route, you might find something like this useful so that all posts are taken care of: RewriteRule ^news/(.*)$ /blog/$1 [L,NC,R=301]

@owzim see my post above where I explain this.... http://processwire.com/talk/topic/4189-flexibility-in-page-design/?p=45581 But repeaters don't support field dependencies (yet) I just hacked it into to recognize dependencies and it would work. and here I meant http://processwire.com/talk/topic/4189-flexibility-in-page-design/?p=45565

Hi desbest and welcome to PW! The plural version is the parent template and the singular is the template for the child pages which contain the actual posts and tags. This allows different rules for the parent and child templates. It allows you to say that any children of the tags page must use the tag template. Look at the page tree for Tags: Tags (tags template) CSS (tag template) Customization (tag template) Photography (tag template) Templates (tag template) Uninteresting (tag template) Videos This also allows for creation of a Tags PageField that allows for selecting these tags on other pages (eg from a post). It's all about structuring the content and defining what is allowed to be used where. Here is a great tutorial from kongondo about page structuring: http://processwire.com/talk/topic/3579-tutorial-approaches-to-categorising-site-content/ This video about page fieldtypes might also be useful: http://processwire.com/videos/page-fieldtype/ Hope that helps - let us know if you have any more specific questions.

Getting stoked The latest version on github now supports migration of repeater field page content and fixes the problems with migrating page field content. That should take care of migrating the fields, templates, and page content for all the field types, not including page content for file and image fields as obviously these can't, or more accurately, shouldn't be included in a json file. Multi-language fields should migrate perfectly so long as you have the required language support modules and languages installed on the destination PW installation. Let me know if you have any troubles here - I did see some weird errors during early testing - I hope they are all fixed now. Please note: that most of my testing of late has been with the "Everything, including all data pages" option on export and import. I need to go back and test the other options soon, but I'll probably do that when I start implementing the series of checkboxes allowing you to select exactly which fields, templates, and pages to be exported and imported. Also, I have been testing with the latest dev version of PW (downloaded today). Not sure if anything is critical, but if you are getting errors, please try upgrading PW first.

ok,finally i found the reason caused these issues. my MySQL Database Version 5.0.51b, and i upload to my server (MySQL Version: 5.0.95) ,its work perfect. this topic is helpful.. http://processwire.com/talk/topic/4047-drag-and-drop-page-sorting-with-blog-profile-not-working/ thanks all.

I've been working on making repeatable fields for ProcessWire for a couple weeks and actually now have it nearly ready. I need to do some more testing before releasing it, but wanted to give you a little preview. (please view the full screen version for better quality) Accessing repeatable fields from the API is super-easy. They are fully searchable/selectable with the API just as easily as with any other fields. So if you wanted to find all pages that had a buildings field with a floors value of 50 or more, you'd do this, for example: $pages->find("buildings.floors>=50"); Lets say you are on the page with a 'buildings' field and you want to print out all the building names and number of floors. It works exactly the same as page references: foreach($page->buildings as $p) { echo "<p>{$p->building_name}</p> has {$p->floors} floors.</p>"; }

Template Cache and $page->render($options) If you ever use the $page->render() to render out partials (of another page using its template file) and use template cache for the pages you're going to render and the page where you render it, it will create a cachefile. So if you go to that previously rendered and cached page, it will render that partial. If the page is accessed before a cache is created, it will cache this one and render that in as the partial, so kinda turned around. Funny effect. And many mmms and oaaahhhs To get a better understanding what's happening read on. Simple example code from a list page to render partials of articles (likely) // from the list pages template $markup = ''; foreach($products as $key => $child) { $markup .= "<dl>"; $markup .= $child->render(array('isOverview' => true, 'class' => $class)); $markup .= "</dl>"; } echo $markup; And in the template of the article // in article template file if(isset($options['isOverview']) && $options['isOverview'] == true) { // render small partial $class = $options['class']; $markup = "<dd class='$class'> <h4>$page->title</h4> <p>$page->summary</p> <a href='$page->url'>details</a> </dd>"; } else { // render complete article $markup = "<div class='product-details'> <h1>$page->title</h1> $page->body </div>"; } // output echo $markup; So now the render call $markup .= $child->render( array('isOverview' => true, 'class' => $class) ); in the list template will cache the page it renders (the small view of it). Thus if you access the page directly it will serve the cached small view of it. Ups. Solutions This is without specifying a different template file in the first argument in the render(). The effect doesn't happen when you, let's say create a new template file (ie article-small.php) and use that to render the page. Since this new template file is not connected to the template in PW it also has no cache for that render. To show what I mean is the following with the first argument the file you want the view to render. $markup .= $child->render("product-small.php", array("isOverview" => true, "class" => $class)); Still following me? Ok there's also another method to not allow a cache file to be created. There's a default options set in the render() in PW. Bingo! allowCache is what we can also use. $markup .= $child->render("product-small.php", array( "allowCache" => false, "isOverview" => true, "class" => $class )); And everything's back to normal. Just wanted to write down a little thing, as I stumbled over this recently, to scatter some keywords about this here . I think this isn't really documented somewhere but I thought it was maybe mentioned by Ryan in a thread about when he added this feature: http://processwire.com/talk/topic/3145-multiple-views-for-templates/page-2?hl=%2Brender+%2Bcaller#entry32876. Edit: Zaaakkkk and it's in Google 9 minutes !

I found myself searching for an smooth workflow to collaboratively work on a process wire project and had the challenge of including the mysql data into version control to keep it in sync with the rest of process wire. Here is a solution with git hooks, that Ben Kubertis came up with: http://ben.kulbertis...-and-git-hooks/ Step 1: When commiting you want to fetch the latest changes of the database. Edit the "pre-commit.sample" hook located in /YourRepoDirectory/.git/hooks/ #!/bin/sh mysqldump -u [db_user] -p[db_password] --skip-extended-insert [db_name] > /PathToYourRepo/database.sql cd /PathToYourRepo/ git add database.sql Enter your mysql login details and git repository paths and then save and rename it to "pre-commit" That way each time you commit, any changes of the db will be downloaded and kept under version control Please note: If you only have modified the database and didn't touch any other files, you will have to manually pull the database updates, since git commit needs "changed files" to successfully commit. Step 2: When you checkout or merge branches, then you always want to fire up the belonging database again. Create another two hooks named "post-merge" and "post-checkout" with the following content: mysql -u [db_user] -p[db_password] [db_name] < /PathToYourRepo/database.sql NOTE: !!! Please test this first on a dummy project, in order to not mess your database up !!! When working with MAMP you probably have to add the path to mysql and mysqldump as well; Simply put /Applications/MAMP/Library/bin/ in front of it

Hi all, I'm a big fan of the Sublime Text 2 text editor and of course of huge fan of ProcessWire, so I went ahead and created a library of PW snippets to be used with the ST2 Snippet system. I followed the PW cheat sheet, and created Advanced and Basic versions. The Advanced version contains only those seen in the advanced mode of the cheat sheet, so if you want the full set, you'll want to get both Basic and Advanced. They are on GitHub here: https://github.com/evanmcd/SublimeProcessWireSnippetsBasic https://github.com/evanmcd/SublimeProcessWireSnippetsAdvanced I've just submitted the Advanced set for inclusion into Package Manager, so hopefully that will be added soon. See the README for more info. Any feedback welcomed

Hi folks, I'm currently engaged as a consultant for a lager scale web project. I advise on strategy, information architecture, content etc. but very few on the operational side of things. Coding will be done by guys that favor Joomla as CMS platform to go. Apart from my personal like of PW, I've never ever heard anything positive about Joomla from the community and I'm almost convinced that it is not the right choice for an enterprise-level project like ours. However, I'm lacking arguments as I have no experience with the system and everything I "know" is from hearing. Knowing all the pros for PW from my own experience I would like to learn what are your arguments against Joomla? Glad if you could give me an idea from your point of view. Maybe there is a small chance I can position PW as better alternative or - if not - at least avoid a wrong decision and vote for an enterprise-level system like Drupal or Typo 3. Just to clarify: this is not about bashing a competing CMS, it's about investing a significant budget wise. Thanks.

thanks to everybody who replied so far. i get a better understanding now. very helpful indeed. in particular thanks to matthew and mademyday for your profound insights. not yet. the project is at a very early stage. but unfortunately the project lead, the person that engaged me, made some determinations before they got me on board. one of this determinations are the joomla orientated coders. my advise to her was to set up information architecture first and to make a list of features required and then to decide which cms fits best - as it would be natural to all of us. if you don't mind i'll get back with more detailed questions once the concept has evolved and it comes to decision making.

There are many ways to include a widget area in processwire (just one reason why PW rules!). What kinda of widget are you wanting to include into your side bar? I would start off here and it will give you plenty of ideas. Also, look at the default website that comes with processwire when downloaded. It includes a sidebar area and can give you some ideas. Also check out this post here http://processwire.com/talk/topic/2028-adding-a-google-plus-widget-to-your-sidebar/?hl=widget Hopefully those will get you on your way

Hello, I've recently updated a showcase website for (private) antique collection. http://agcat.net/ Module I used: - Procache - Batcher This website is expected to be written in Japanese/English, but English texts are not available yet. Developing this website, I thought Processwire would be a fantastic solution to organise and show cultural heritage such as museum collections!

It's always interesting when someone wants to put one Open Source project against another. First, we should be supporting, where possible, any Open Source project, especially PHP based ones. I honestly believe time is better spent with actual Case Studies and other technical documents that show the benefit of using ProcessWire over those systems and others.. I've used Joomla, Drupal and Wiordpress in the past. The botom line is that each and every project has it's inherent weaknesses and plusses. Some more than others. That's my two cents on this issue. Good Day.

In InputfieldWrapper.php around #302 and looks like this if(strlen($showIf)) { if(strpos($inputfield->name, "_repeater") !== false){ $rep = explode("repeater",$inputfield->name); $showif_part = explode("=",$showIf); $showIf = $showif_part[0] . "_repeater{$rep[1]}" . "=" . $showif_part[1]; } $ffAttrs['data-show-if'] = $showIf; $ffAttrs['class'] .= ' ' . $classes['item_show_if']; } I thought maybe Ryan would read this and implement support for repeaters too, but you know how it goes...

I just thought of yet another approach to flexible page design: Repeaters and the new Field Dependencies. So you set up a couple of block types via a page select (text with image, three columns text, employee, gallery or whatever blocks you want to use), those options are available in each repeater item and according to what is selected you show and hide fields within the respective repeater item. Then in the template you can use the new option to pass alternative template files to a page to render the blocks: foreach ($page->repeater as $repeaterItem) { echo $repeaterItem->render("blocks/{$repeaterItem->type}.php"); } This might be closest to what I would expect from patching a flexible page layout together.

Go to the /wire/modules/Process/ProcessTemplate/ProcessTemplate.module #299 and replace the line with $row["{$numPages} "] = "$numPagesLink"; // space is required to make it work and you'll have the number pages count in the template table the search link. The $numPagesLink is already there but not output, maybe Ryan wanted it to add there but forgot.

There is a great post (I think of Matthew's somewhere) where he goes on a big rant about Joomla, that would be a good a start. No custom fields Very poor security track record Bloated code Nightmare to template with

let's say you have the following structure: - mypage -- post 1 -- post 2 -- post 3 etc. a post consists of a title and a text (to keep it simple). your goal is to display all content (title and text) from the posts on "mypage". that's pretty easy: 1. make a template "post" (it doesn't need to have a template file. it's just for holding the fields) with a title and a text field. assign it to your post pages and fill with content. 2. make a template "my page". assign it to mypage. from this template you loop over the child pages ("post") and retrieve their content. for example: <?php foreach($page->children as $post) echo "<h1>{$post->title>}<h1>"; echo "<p>{$post->text>}<p>"; ?> that should to the trick. EDIT: adrian was quicker. And sorry for the formatting of the code (which is not tested).

Just tested on smartphone with 3G conn. Nice site. Fast too (from holland)

Would be cool to create a project management system using Processwire.. with the help of something like http://dhtmlx.com/ components. What do you think?

Oh yeah, it makes sense now. Thank you so much SOLVED!

I think what you want is to hook after ProcessPageAdd::buildForm. That returns an InputfieldForm object, that you could manipulate with an 'after' hook. The only problem is that method isn't currently hookable. But you can make it hookable by editing the file and prepending 3 underscores to it, i.e. "buildForm" => "___buildForm". I will make this same change in the core source and you'll see it in the next batch of dev commits.

This is good discussion in my opinion. I agree with both, Felix and slkwrm. It is very important to keep things up to date and use best practices. As Ryan has many times stated, he is more "in home" with PHP than front end stack. But in the other hand using too many "cutting edge" methods/libraries/etc is dangerous too: it always makes steeper curve to learn and start using. Anyways: I am really enjoying this discussion and the constructive tone that Felix is leading here!

1) Migrations I had the same problem during my work with Processwire. If you have a team working on a Processwire project where everyone has his own dev server then you need to be able to version the "structure" you put into Processwire and keep it in sync with the template files. I found it to be important to strictly distinguish between structure and data. In 90% of the cases this means templates and field can be seen as structure and pages would be the data. In my current project I tried to use the concept of migrations with Processwire utilizing the phpmig library. If you strictly create all of your "structure" with migrations and never with the Backend UI then it works perfectly, your structure is always in sync with the template files and you can put both in your favorite VCS. To give you an example of how this works: https://gist.github.com/webholics/6191779 2) Structure vs. Data I'd like to add more thoughts to the problem of mixing structure and data in CMSes. This is not a problem only Processwire has, but most CMSes do this (in my opinion) wrong. If your main target user group are developers, it should be possible to keep those things separate in order to enable professional workflows like continuous integration and TDD. This is only possible if you define the structure in code or in config files and not in the database and via a backend UI. It is always the case that template files and structure are strongly depended on each other. One CMS - I'd like to mention here for inspiration - which implements this concept perfectly is Bolt (http://bolt.cm/) . They use YAML files to configure the database models. Bolt then tries to keep them in sync with the database. Maybe it helps to have a look at how they did it.