Leaderboard

This module goes through all of your /site/assets/files/ directories and removes those that have no files in them. http://modules.proce...ean-empty-dirs/ Pages with file/image fields require a directory, so you should expect that some of the removed directories will be re-created by these pages. As of today, ProcessWire no longer creates directories for all pages, so this module is mostly useful to existing sites rather than future sites. I am listing it as "alpha" just because I've only tested on my own sites. Once I get confirmation from others that it also worked well for them, I will change its status to stable. Until it is considered stable, I suggest only running it in dev/test environments (not that it does anything dangerous, but just a good practice).

MODx is a great tool. No doubt. However when I compare the code and work required get things done in it versus PW, PW comes out ahead as a winner for the types of sites my shop builds. We are busy converting three content heavy sites from MODx. These were due for upgrades from MODx Evolution. There are another dozen that will be in the switch over queue before too long. I worked with MODx Revo and deployed a few sites on it, but honestly there was a lot of extra overhead and a new API to convert our custom modules (snippets) to. I could not justify the work to upgrade as I did not see enough benefits. Clients will pay for new features, just usually not for the coding required to update the backend. I felt a sense of dread, instead of excitement, when I heard the news of MODx V3. The API has completely changed once already and I was not excited to start over again, again. Not knocking MODx here, built some well performing sites with it. Even donated $. I wish the team continued success. I decided to keep looking around for a better solution. I have used EE, Drupal, Wordpress, Pyro CMS, and a few others. Each with different strengths and weaknesses. Luckily came across PW. Lurked for a while, kicked the tires, built a few mockups. Discovered that all the things I typically need to do, are simple calls to the API, and some logic coded in PHP. Everything is an extension of the API. The front end, the back end. I love the whole concept of leveraging the document tree, getting parents, siblings, children, and the whole ancestry easily through the API. This matches with the type of highly structured sites I usually build. The selector logic make it simple to pull content from wherever it lives. I can park any kind of structured content wherever I see fit. Usually the CMS interferes with the IA. Not with PW. The PW API is very clean and so is the logic. I am very productive with it so far, and it has exceeded my expectations. The content editors like the backend and find it easy to work with and publish / update content. PW has moved front and center in the shop and will be the basis for most all CMS projects going forward. No going back. Kudo's to Ryan and the forum participants, who are generously sharing here. Welcome to PW.

Thanks guys, these are some great references! And Ryan; my compliments for your work on ProcessWire. It would have taken me many years to have gotten my own cms somewhere near the current state that ProcessWire is in. But instead I’ll try spending that time to contribute wherever I can, and I’ll ofcourse be sure to share my first module!

I just pushed an update to the source that should prevent it from creating directories for pages that don't need them. Next up: going to make a module that removes empty directories, for those that want it.

I found (after 2-3 Projects using PW) that it's a good technique to use templates in a way I think hasn't been thought of yet really by some. (Although the CMS we use at work for year, works this way.) I'm sure I'm maybe wrong and someone else is already doing something similar. But I wanted to share this for everybody, just to show alternative way of using the brillant system that PW is. Delegate Template approach I tend to do a setup like this: - I create a main.php with the main html markup, no includes. So the whole html structure is there. - I then create page templates in PW without a file associated. I just name them let's say: basic-page, blog-entry, news-entry... but there's no basic-page.php actually. - Then after creating the template I make it use the "main" as alternative under "Advanced" settings tab. So it's using the main.php as the template file. - This allows to use all templates having the same php master template "main.php" - Then I create a folder and call it something like "/site/templates/view/", in which I create the inc files for the different template types. So there would be a basic-page.inc, blog-entry.inc ... - Then in the main.php template file I use following code to delegate what .inc should be included depending on the name of the template the page requested has. Using the TemplateFile functions you can use the render method, and assign variables to give to the inc explicitly, or you could also use just regular php include() technic. <?php /* * template views depending on template name * using TemplateFile method of PW */ // delegate render view template file // all page templates use "main.php" as alternative template file if( $page->template ) { $t = new TemplateFile($config->paths->templates . "view/{$page->template}.inc"); //$t->set("arr1", $somevar); echo $t->render(); } <?php /* * template views depending on template name * using regular php include */ if( $page->template ) { include($config->paths->templates . "view/{$page->template}.inc"); } I chosen this approach mainly because I hate splitting up the "main" template with head.inc and foot.inc etc. although I was also using this quite a lot, I like the delegate approach better. Having only one main.php which contains the complete html structure makes it easier for me to see/control whats going on. Hope this will be useful to someone. Cheers

After Ryan's latest incarnation of Blog Profile I wanted to see if I could learn something from there to my own workflow. It turned out very nicely and this seems like a perfect template approach for me. Wanted to share it with you guys. Folder structure under templates folder: templates/markup/ templates/markup/helpers/ templates/markup/layouts/ templates/scripts/ templates/styles/ And it all begins from here: templates/markup/index.php -this is the "complete" html file, it has doctype, head and starting and ending body. There is very little "logic" here, it's more like a container. There is one very important code snippet there though: <?php if ($page->layout) { include("./markup/layouts/{$page->layout}.php"); } else { include("./markup/layouts/default.php"); } ?> Code above goes between header and footer of your site, that will be the main content. I call it layout, but the better name would be "content layout" or "inner layout" or something like that. Then the templates/markup/layouts/ folder will keep at least default.php file, but probably few others, like "threeColumns.php", "frontpage.php", "gallery.php" etc.. you got the idea. Each of the actual pw template files are then purely "controllers" - no actual markup generated there. All markup are done in files inside templates/markup/ folder and it's subfolders. This is how template file templates/home.php on one site I am building right now looks like: <?php // Carousel items $t = new TemplateFile(wire('config')->paths->templates . 'markup/helpers/carousel.php'); $t->set('carouselPages', $page->carousel); $page->masthead = $t->render(); // Tour themes $t = new TemplateFile(wire('config')->paths->templates . 'markup/helpers/items.php'); $t->set('title', "Get inspired from our <strong>tour themes</strong>"); $t->set('items', $page->featured_themes); $t->set('description', $page->themes_description); $t->set('url', $config->urls->root . "themes/"); $t->set('linkTitle', "All themes"); $page->main .= $t->render(); // National parks $t = new TemplateFile(wire('config')->paths->templates . 'markup/helpers/items.php'); $t->set('title', "Seven beautiful <strong>national parks</strong>"); $t->set('items', $page->featured_parks); $t->set('description', $page->parks_description); $t->set('url', $config->urls->root . "national-parks/"); $t->set('linkTitle', "All national parks"); $page->main .= $t->render(); $page->layout = "frontpage"; include("./markup/index.php"); This uses few "helper" markup files from templates/markup/helpers/ folder (namely carousel.php and items.php). Here is the carousel.php for your reference: <?php /* Generates the markup for the frontpage carousel */ if (count($carouselPages) < 1) return; $styles = ''; echo "<div id='carousel'><ul class='rslides'>"; foreach($carouselPages as $key => $p) { echo "<li class='c-item c-item-$key'>"; echo "<img src='".$p->image->getThumb('carousel') ."' alt='' />"; echo "<p>$p->summary</p>"; echo "<a class='button' href='{$p->link->url}'>$p->headline</a>"; echo "</li>"; } echo "</ul></div>"; Then populates the $page->masthead and $page->main properties and then set's the inner layout to "frontpage". That templates/markup/layouts/frontpage.php file is very simple on this site, but could be much more complicated if needed: <div id="masthead"> <?= $page->masthead; ?> </div> <div id="main" class="wrap"> <?= $page->main; ?> </div> Frontpage is rather unique and I could have done all the markup on the frontpage.php file also. But I do want to re-use those "carousel" and "items" components on other places as well. But if I do have totally unique stuff, where I do want to get "quick and dirty" this approach allows it. Then my template file would be something like this: $page->layout = "campaign2012"; include("./markup/index.php"); And then all the markup would be in that templates/markup/layouts/campaign2012.php Blog profile really gave me a good ideas (cleaner folder structure etc) and using TemplateFile class adds nice possibilities. This is of course just a one way to manage your templates, but hopefully someone of you finds this helpful when thinking about how you like to structure this stuff. PS: If you are just getting started with PW, then I recommend using the head and foot includes method from demo install. There is nothing wrong with that method and only more complicated sites starts to benefit from these methods introduces in this topic.

If anyone wants to stake a stab at it, I think this is where I would start if I had a windows machine to test with. This is in the file /wire/core/Pageimage.php: public function removeVariations() { $variations = $this->getVariations(); $this->message("There are " . count($variations) . " image variations"); // ADD THIS foreach($variations as $variation) { $this->message("Removing file: {$variation->filename}"); // ADD THIS if(is_file($variation->filename)) unlink($variation->filename); } $this->variations = null; return $this; } The two lines above that say "ADD THIS" are the ones I'd add to this file. Now when you delete an image, you should get your messages on the next screen. Let me know what you get? Thanks, Ryan

Very nice post from Barry ProcessWire, my new favorite CMS in the whole wide world!

This opens up a new door. I have to study...

It is already double click to edit. If you train some you get pretty fast with it.

@SiNNuT either here or GitHub is fine. But since we're here, might as well just submit it here. I did commit a few updates this morning, including a fix for the /site/profile/ vs. /site/templates/ typo. I honestly have no idea where I got /site/profile/ from… I need to get more sleep.

I don't know about anyone else but I'll definitely be using some of this code to improve my own sites.

Here is the first release version of the Blog Profile! http://modules.proce...s/blog-profile/ It is now up on GitHub as well: https://github.com/r...ign/BlogProfile Below is a lot more talk about this blog profile and how it works, but if you just want to install the profile and test it, it's not necessary to read anything further unless you want to. I've simplified this a lot from where it's been. It does all the same stuff on the front-end, but the code behind the site is no longer a huge departure from the basic profile. I've rebuilt this profile 3 times trying to find the right balance between making it as flexible as possible and making it as easy to understand as possible. I think it's got a better balance now than before. It's now at a point where it does everything it always has, but the template code behind it should be a lot more accessible and easy to understand. There is no longer a separate module or API variable. Everything here just happens in /site/templates/ files. Consistent with making it simpler, I've also removed the drag-n-drop theme support. While it was cool to have, it always felt a little dirty introducing some kind of proprietary theme support that was so different from the way I'd build any other site. This thing is pretty darn simple to theme as it is (just edit a CSS file). Maybe we'll take it further in the future, but we don't have many PW site profiles out there right now (1 or 2?) and so I decided this profile needed to stay more accessible on the back-end. How the template files work In ProcessWire there are any number of ways you can use your template files. In this case, we are using our template files (in /site/templates/) to populate 3 variables ($content, $headline and $subnav) and then including an HTML file (main.inc) to output them in the right places. The $content variable represents the center (body) column, the $headline variable represents the text headline of the page, and the $subnav variable represents the navigation that appears in the left sidebar. Once one or more of these variables is populated, the template file includes the /site/templates/main.inc file. That main.inc file is just a big HTML file that outputs the $content, $headline and $subnav variables in the right places. We've made an attempt here to separate most of the logic used in the template files from the output. Most of the markup is generated from files in /site/templates/markup/. These files are included from the template files to output specific things like a blog post, comment, etc. Because a lot of output needs are similar among the various template files, we've created a file called /site/templates/blog.inc that has a few shared functions in it. If you look in any of the template files, you'll see that most of them include blog.inc as the first thing. This blog.inc file also initializes our $content, $headline and $subnav variables, mentioned earlier. Outline of /site/templates/ with this profile /site/templates/blog.inc Shared blog-specific functions included by most site templates. /site/templates/main.inc The main HTML markup file through which everything is output. /site/templates/markup/ Contains PHP files that generate markup for specific things like posts, comments, etc. This is separated from the site templates to make it simpler for you to modify the markup if you want to. This is primarily used by the blog.inc functions, but also included by a couple templates as well. /site/templates/skeleton/ This is the Skeleton CSS framework. It is identical to the one they distribute except we added a wider viewport to it. You probably wouldn't have much need to edit anything in here. /site/templates/styles/ Stylesheets used by the blog profile. The most useful one in here would probably be theme.css, which contains all the color definitions for the profile. /site/templates/scripts/ Javascript files used by the blog profile. Not much is happening in here at present.

I agree, though also think it's a delicate balance. I'd like people to perceive ProcessWire as something like Google (in terms of simplicity) – they can start using it without really having to know anything. They can discover the depth of it as their needs grow. If the depth is out in front, they might be overwhelmed. So I like to keep lots of surface simplicity and let PW grow with them. Most of what you use PHP for in a template is no different than how you would use some other template engine, except in syntax. So something like: <p>$somevar</p> is probably not a good example because there is no logic there, it's just pure output generation. You have to connect your variable to the markup at some point, and it doesn't get any simpler than that. I do think the point is valid when you get down into code that isn't geared towards output generation. But the nature of PW's API is that all the data is put at your fingertips so your template code can focus on output generation. The logic (or lack of it) that one uses in PHP at this level isn't really any different than that provided by something like Smarty, EE or another template engine. What is different is that PW puts all of the site's data at close reach, rather than some specific subset of it. That kind of resembles working in Javascript with the DOM. As you start working at a larger scale, using some discipline in how you do things can help you in the long run. I'm not talking so much about whether something is in a <p> or <li> tag, but about stuff that would create major obstacles if you wanted to completely re-skin your site tomorrow. An example of something that does go beyond output generation a little is a search engine. This is one of the reasons why I like the approaches we've been talking about, because it does a good job of isolating logic where it matters. This particular example doesn't have any real logic of the sort I'm thinking of, but pretend for a moment that it was a much bigger/more complex search engine: search.php <?php $q = $sanitizer->selectorValue($input->post->q); $results = $pages->find("title|body|sidebar*=$q"); $page->body .= $results->render(); include("./main.php"); Or using something like your guys method, where a separate view file generates output separately: search.php <?php $q = $sanitizer->selectorValue($input->post->q); $page->searchResults = $pages->find("title|body|sidebar*=$q"); /* then the output file /includes/search.inc knows to output results from $page->searchResults */ include("./main.php"); Another thing I've found that works well is to put reusable output generation in modules and attach it to PageArrays, not unlike $results->render(). For example, on those villa sites, I have a PageArray::renderVillas hook that can be called anywhere in the site and it always renders villas the same way, provides a sort select at the top, and knows to handle pagination. Likewise, I added a Pages::villas() hook that only finds villas and automatically plugins in the proper limit=n for consistent site-wide pagination. So if I needed to re-skin the site tomorrow, I could update all the site's villa lists in one shot (and there are hundreds of them). As time goes on, I think it'll be good for us to document best practices for large scale use. Like with PHP itself, I'm glad PW doesn't force us into one way of doing things. But I think it'll be helpful to lots of others if we outline what we've found helps to maximize scalability, longevity, etc. At the same time, when it comes to teaching people how to use ProcessWire with examples, I think some of these best practices can confuse the message. I wouldn't suggest that someone learning ProcessWire should use it in pure MVC mode until that is appropriate for their scale and need. It's only when you go bigger and more complex that your template code starts to become something more than a 'view', and it's at that point where you need to start considering the long term. I think this is only worthwhile if you are dealing with some other group of people that is creating the output files, and that group refuses to get anywhere near PHP. Ultimately they just need to be told that there's no difference between <?=$somevar?> and {{$somevar}} except for a lot of unnecessary overhead for the {{$somevar}} version. More here: http://processwire.com/api/why-php-syntax/ It would be easy possible within PW to create markup-generating type of modules. Not sure If that should be done, as It's a little against PW's philosophie. Markup generating modules are fine I think, but I just don't want PW's core to generate any markup. I figure it should always be markup neutral. But markup generating modules can be very handy. Though my preference is for markup generating modules to provide options for customizing that markup. Me too. Though when providing these as something beyond a basic example, I think it invites an audience that is interested in turn-key solutions and not web development. Such things require good support. Thats why I think there is a good fit for paid solutions in this (like Maruchan brought up).