Leaderboard

Module: MinifyHTML Simple module, didn't even plan to add it to the forum untill owzim asked me to. Description: This module takes the HTML output and then minifies it, and removes all comments from it but leaving the conditional comments in place. Usage: Just install, nothing to configure, works automatically. URL: http://modules.processwire.com/modules/minify-html/

why you.say that ? i not rodericdo affended why i.get feel you secret.jooomla user

We've just launched a new company, early days and we needed to get a site out quickly. http://www.milktop.co.uk Still plenty of fiddling to be done and we're pretty busy on other work, just didn't want to be one of those web companies without their own site

Hey, I'm planning to do a Interrail trip through Europe in July. The trip will (hopefully) look like this: Berlin -> Amsterdam -> Paris -> Bordeaux -> (Madrid) -> Lissabon/Porto -> Wien/Vienne -> Berlin Now I have to look for some places to stay and I thought maybe here are some people who live in the cities mentioned above or next to them and maybe have a idea where to stay for 2-3 nights per city... (Like for example I saw that diogo is living in Porto so it would be lovely to maybe meet you and say hi or stuff like this ) Would be really, really lovely if someone here could support me here! Much love to processwire community <3 Nico Btw.: The website isn't ready but running with PW of course: http://interrail.nico.is

Hi guys, Finished this one up in Jan, been meaning to post it. Have a few more that are done but need some final polish, I'll post those up soon. www.contactla.com - Pretty simple site, but client was extremely happy with the setup and how easy it is for them to change content/pricing tables. Can't really express how much I enjoy doing sites in processwire. THANK YOU RYAN !!!!!!

I moved few posts from here to another topic: http://processwire.com/talk/topic/3186-roderigo-maryla/ Also removed the ones that were discussing about moving to another topic to keep this focused. We do love good fun, but since clients also looks for these topics (through Google etc) it is nice to keep these showcases on topic.

Coming from here http://processwire.com/talk/topic/3130-website-for-a-hotel-in-karlsruhe/?p=31239 Thanks, but the image that is on the menu is already great Roderigo, you are amazing!

I'd like to see something like this too. A subdomain would probably be best to keep it all in the family. Although the builtwith.pw domain is free available - for the moment.

I just posted an update to the LanguageSupportPageNames module that appears in the 2.3 dev branch. The screenshot explains it best: Basically, you can uncheck the "active" box for any language, and that page becomes unpublished, for that language only. It behaves the same way as an unpublished page, in that it doesn't show up in searches, and produces a 404 if you try to view it (unless it's editable, in which case you can still see it). You don't see a checkbox next to the default language, because that one is controlled the same way as before (via the page's unpublished status).

Wow to you Apeisa, you're one of the big reasons I stuck around long enough to know my ass from my elbow (as we say in the UK)! I love the first part of your comment (I did know I was being annoying by the way ) but I feel very uncomfortable and unworthy of the last bit! Anyway, thanks mate, I'm so happy to be here, believe me! PS Also work with another guy, Ruhul, so can't take all the praise

This is easy one to like really. We old foxes all remember you as "the one who asked about every possible (and impossible) question there is". Sometimes it almost felt you were there to annoy us It didn't took long though and soon you started answering other member's questions with great answers. And now we also see very unique and high quality PW-site coming from you! All this in under a year.. just wow and congratulations! It's great to have you here.

Jeez, thanks guys, made my day

I don't care who they are, as long as they keep posting.

I read both your messages in the same voice! Don't be affended Now... where did I leave my Joomla badge...

Maybe the default templates could be an optional part of the setup process. Perhaps an advanced options area to turn off their creation?

Joss actually emailed me a similar question and I'll duplicate my reply here since it seems relevant: Performance as it relates to database is really not an issue that one needs to consider much (or at all) when it comes to creating their fields. Most field data in ProcessWire is loaded on-demand. It loads data selectively and only when it needs it. This enables it to be highly memory efficient with large quantities of pages in memory at once. When you have a $page, behind the scenes, none of the page data is actually loaded until you access it. For instance, if you access $page->body, then it goes and retrieves it at that moment (if it hasn't already retrieved it before). MySQL is extremely fast with simple primary key, non-joined selects, and we take advantage of that. What I'm trying to get across is that quantity of fields does not translate to an increase in joins or other factors that would slow the system down. Where ProcessWire does join data automatically is at page load time is when you check the "autojoin" box on a Field's "advanced" tab. Some fields you know will always be needed with every $page instance, and that's what autojoin is for. Typically, I make my "title" field autojoin, as it is already by default. I've hidden that autojoin option under the Advanced tab simply because most people never need to consider it. The original intentions behind autojoin have become less applicable than I originally thought [with regards to performance], so it's not something that comes up that often. ProcessWire also uses joins when it performs queries for $pages->find("selector"), and related DB-querying selector functions. It joins all the tables for fields that you query. So if you perform a find for "date>2012-12-19, body*=holidays" then it's going to join the field_date and field_body tables when a value matches. Though it doesn't do this for the purpose of loading the data, only for matching the data. Technically this type of query could be potentially faster if all those fields were in one table. But that doesn't translate to results that matter for us, and doesn't affect the way that you should use ProcessWire. The benefits of our one-table-per-field architecture far outweigh any drawbacks. I put a lot of time into finding the right architecture and balance here when coding ProcessWire 2. Incidentally, ProcessWire 1 did use the one-table approach (all the field data was stored with the page rather than in separate tables) and it was far less efficient with memory, and about the same in terms of performance. It's better to re-use something like "body" (when possible) rather than create "article_maintext" or other template-coupled variations like that. The reasons for that are for your own benefit. It is less to keep track of, and tends to foster better consistency. It also results in more reusable code and broadens the potential of where the data can be used. Take the example of an on-site search engine, like you see in the upper right corner of processwire.com. If we know that the main text field(s) of most templates has some consistency in their field names (like title and body), then we can write code that doesn't need to know whether something is an article, a press release or a product. We can find all pages that match "holidays" in the text just by doing this: $pages->find("title|body*=holidays"); But if created a separate textarea field for every template, then any code that queries those fields needs to know a lot more about them: $pages->find("title|article_maintext|pr_maintext|product_maintext*=holidays"); While that still works, it doesn't scale nearly as well. This also translates to the code you use to output the results. If you want to show a snippet of the matching text with the search results, you are going to have a lot more fields to consider than just "body". Now if each of your templates genuinely needs very different settings for each of their main text fields, then of course it's fine to create them as you need them. But in the real world, I think you draw more benefit by planning for reusability when possible. The benefits are for you (the developer), as it doesn't matter much to ProcessWire. Reuse fields where it's obvious that the name of the field makes sense in the context of multiple templates. If template "employee" needs a date_of_birth field and template "press_release" needs a date_publish field then just create one field called date and use it on both templates. On the other hand, if you need multiple date fields on the same template (like date_unpublish) then more specific field names start to make sense. In that case, I would usually use my date field for publish date, and create a separate date_unpublish field for my unpublished date field. Though some may prefer to actually have separate date_publish and date_unpublish fields because they are obviously related by name. Ultimately, use what works best for you, but always keep an eye out for obvious reusability potential with fields. I think that most people naturally arrive at the right balance for their needs after some experimentation. What is a best practice for one need might not necessarily be for another. So these are mostly general purpose guidelines and people should find what makes the most sense in their context. For the majority of cases, I think avoiding tightly coupled template and field names is a better strategy. TL;DR: It doesn't matter to ProcessWire what you do. Aim to reuse fields when you can and when it makes sense, for your benefit.

Hey guys, another green website from the processwire beginners based near munich. This website is our first REAL PW project - and (for us) one of the biggest sites we‘ve ever built. And actually the first one with a CMS/framework that we did totally on our own. So, don‘t be too negative - but don‘t be too positive either. http://www.roha-gmbh.de There are still many things that are not perfect yet, but since we started to design this website in 2011, it really was time to get it "into the wild" now! Many furniture manufacturers still haven‘t sent their best product images, so that is why there are still some lowres images in there. The project chapter needs some work on the photos as well, but that time will come... The site is not responsive yet, because it wasn‘t our main goal in 2011 - so we only wanted to get it working on tablets and phones, but without any special mobile styles. This will come, but that may take a while. The modules we used: - formbuilder - procache - redirects - versioncontrol - sitemapxml I‘m totally glad I found processwire a few months ago, because at first we planned to get that site done with pure static html. Which would not be TOO nice with about 80 html pages and many, many images (about 400). Finally a few "thank you"s to ryan, soma, diogo (for creating processwire and your help in this lovely forum) and to mademyday (for posting this on twitter, which made me read about processwire). Comments are welcome! Of course!

Hi this is my new onepager site for the thesouplibrary.com using: processwire jquery scrollto.js parallax.js

Imagine a hotel website. Done? Yeah, most of them look the same ;-) In this project I took another approach. The client is - thank PW - able to (re)create the whole look of his website by changing tiles (images, sizes, texts). The size adapts to the screen size, so on nearly every device the look is different. But not the user experience. After one week online I can say: It works. Thanks to a lot(!) of image material and an engaged client it is one of the biggest sites I've ever made. There is a lot to discover (only german yet, english is due in May). So click around... Der Blaue Reiter - Design Hotel Karlsruhe

Another great site in the Showcase! The typography's just perfect, really love what you've done here and I very much agree with the last line!

Love it Georgson. It looks immediately professional, I love the type and my favourite part, definitely the navigation! Great job

Great site Nico!

Anyway: I really like the hotel website. Me personally, I would never use photos that way - one reason more why I like that style!

Since I visited the link under his profile, Roderigo is a constant presence in my day. I see this everywhere ...not that I mind. It's much better than the usual publicity.

Edit: Wanted to add something I forgot. You can also enable davanced mode (config.php) and you'll have a select underneath the fieldgroup on the template edit screen to select a Fieldgroup from another Template. It will reference the fieldgroup of that template and and stay connected that if you change the original it will reflect on the template that share the same fieldgroup. This could also be used (instead of cloning) to have different templates having same data type but have a different name thus a different template file. BTW the whole admin backend is done using one template 'admin' using processes you define on a admin page to tell what functionality or controller it has.

"Template" inPW is like a db table with all its fields. If you change the structure of the table you loose data... Except for fields that are the same in the template you change to. Changing a template of a page is not something you do all the time and only to give this page a different content or meaning. It's all about data here and not presentation. "Template File" is more of what you think of in MODX I think, and it's linked to the Template by it's filename. But you don't have to create a file for a template unless you want or need to have it renderable or viewable. The Template name also can be changed, thus mapping it to a different template file. As WillyC pointed out you can also leave the name (which often is used in template code as indentifier and you don't want to change that, unless developing) and define a alternative name that will be used to map to a template file. You can even have all your template share the same template file simply by setting this. A page using a template to build it's data model also isn't locked in to a certain presentation. You can change your presentation template on runtime or have some MVC like approach even. You could even build a simple system to be able to select from different "presentation modes" on a page using page field to build a selection. You make it up. There's many possibilities with how Template and Template Files work together and it allows for some great flexibility in a simple manner. I even after some time working with PW I found ways I didn't see or knew it was possible before, so enjoy the ride. Not sure this is of any help. Always struggle a little explaining this stuff.

wonderful website!!! works great! congratulations..

Hi onjegolders and thank you for your kind words... i hope to manage those fixes. And i really like your sites they are piece of art!!

Why do I get the feeling Roderigo and WillyC are one and the same person?

Welcome to the forum Gas Creature (feels a bit strange to say this ) No, you can't do that. You can only put plain text on the fields, and also html in some (but try not to), but never php. Usually you wouldn't need to have this kind of dynamic content in such a place, because you will always know what is the type of planet when you fill the body (you are inside that planet's page, so you must know). If that need arises... and this would be only to prevent repetition, there are ways to do it in the template file with some more advanced functions http://php.net/manual/en/function.preg-replace.php

think, should be ... $sidebarAd->images->url

I see what you did there

just want to say thanks guys great tutorial!!

Yeah this should work. I figured out how you could add a image and get resized with the InputfieldImage you have. Having this as setting $field->maxWidth = 100; $field->maxHeight = 100; Then when adding the image to page field: // create new page image first $img = new PageImage($uploadpage->images, $upload_path . $file); // add it to page as usual $uploadpage->images->add($img); // trigger the image max size sizing $form->get("images")->fileAdded($img);

Maybe we don't need to complicate. Since a new page will open, we don't need to prevent the click action because it won't be seen. I did this change on ProcessPageList.js and it works pretty well: //line: 403 $("a.PageListPage", $ul).click(clickChild) .dblclick(function(){ window.open($(this).siblings('ul').find('li.PageListActionEdit a').attr('href'), "_self"); });

Thanks for the kind words guys, and for giving the theme a try. I've pushed some fixes to some small issues here and there along with some improved styling to the wire tabs, submit buttons and breadcrumbs. All pretty minor but figured I'd mention it. thanks!

I can't wait to see this site concept with roderigos fine dining photos.

No dis' to niutech. On the matter of commercial components Ryan raises; for me, coming from a CMS platform which was excellent in many ways but that had too little focus on the business of sustainability for the project, I welcome what Ryan et al do to develop commercial grade plugins. What they do for the sustainability and health of the PW project is as important to me as the quality of PW. And not unimportantly, from my albeit limited experience, the cost/benefit and quality of Ryan et al's commercial output has been exemplary and puts many commercial-only products I have used to shame.

This post has been useful to me beyond belief, guys! Just to let you know all your efforts and suggestions are much appreciated!

Thanks for all the suggestions. ProcessWire certainly has an active and helpful community behind it! Cheers

This should do it throw new Wire404Exception();

Thanks for posting Soma, this is an interesting approach and not one I've seen before, but it looks great. The underlying concept and result is similar to the approach I usually use. Since you posted a good description, I'll try to do the same for mine. The only reason you see head/foot files in the default PW profile is because it seems to be simpler for new users to grasp. But I almost never use that approach in my own sites. Like your system, I have a main.php file which is my main markup file. But unlike your system, main.php is included from all the other template files (rather than main.php including them). The other template files focus on populating the key content areas of the site, specific to the needs of the template. Examples of key content areas might include "main" (for center column/bodycopy) and "side" (for sidebar/related info), though often includes several other identified areas. But I'll keep it simple in this case. Here's how it works: basic-page.php <?php $outMain = "<h2>{$page->subtitle}</h2>" . $page->body; if($page->numChildren) $outMain .= $page->children->render(); // list the children $outSide = $page->sidebar; include("./main.php"); main.php <html> <head> <title><?php echo $page->title; ?></title> </head> <body> <h1><?php echo $page->title; ?></h1> <div id='main'><?php echo $outMain; ?></div> <div id='side'><?php echo $outSide; ?></div> </body> </html> The benefit of this approach is that basic-page.php can setup whatever it wants in the key content areas ($main or $side) whether simple like in this example, or something much more complex. I actually prefer for the variables representing the key content areas to be optional. In the scenario above, $outMain and $outSide would have to be defined by every template or they would end up as uninitialized variables in main.php. As a result, I actually use $page as an anonymous placeholder for these variables (making sure they don't conflict with any existing field names) and then let main.php assign defaults if the calling template didn't specify one of them. For example: basic-page.php <?php $page->outMain = "<h2>{$page->subtitle}</h2>" . $page->body; if($page->numChildren) $page->outMain .= $page->children->render(); // list the children // note: no $outSide specified include("./main.php"); main.php <?php // setup defaults when none specified if(empty($page->outMain)) $page->outMain = $page->body; if(empty($page->outSide)) $page->outSide = $page->sidebar; ?> <html> <head> <title><?php echo $page->title; ?></title> </head> <body> <h1><?php echo $page->title; ?></h1> <div id='main'><?php echo $page->outMain; ?></div> <div id='side'><?php echo $page->outSide; ?></div> </body> </html> Final thing to point out here is that main.php is the only template actually outputting anything. Because basic-page.php (or any other template) is determining what's going to go in that output before it is actually sent, your template has the opportunity to modify stuff that you might not be able to with other methods. For instance, the <title> tag, what scripts and stylesheets are loaded, etc. Here's the example above carried further to demonstrate it: basic-page.php <?php // make a custom <title> tag $page->browserTitle = $page->rootParent->title . ": " . $page->title; $page->outMain = "<h2>{$page->subtitle}</h2>" . $page->body; if(count($page->images)) { // display a clickable lightbox gallery if this page has images on it $config->scripts->add($config->urls->templates . "scripts/lightbox.js"); $config->styles->add($config->urls->templates . "styles/gallery.css"); $page->outMain .= "<ul id='gallery'>"; foreach($page->images as $i) { $t = $i->size(100,100); $page->outMain .= "<li><a href='{$i->url}'><img src='{$t->url}' alt='{$t->description}' /></a></li>"; } $page->outMain .= "</ul>"; // add a note to $page->title to say how many photos are in the gallery $page->title .= " (with " . count($page->images) . " photos!)"; } if($page->numChildren) $page->outMain .= $page->children->render(); // list the children include("./main.php"); main.php <?php // if current template has it's own custom CSS file, then include it $file = "styles/{$page->template}.css"; if(is_file($config->paths->templates . $file)) $config->styles->add($config->urls->templates . $file); // if current template has it's own custom JS file, then include it $file = "scripts/{$page->template}.js"; if(is_file($config->paths->templates . $file)) $config->scripts->add($config->urls->templates . $file); ?> <html> <head> <title><?php echo $page->get('browserTitle|title'); // use browserTitle if there, otherwise title ?></title> <?php foreach($config->styles as $url) echo "<link rel='stylesheet' type='text/css' href='$url' />"; foreach($config->scripts as $url) echo "<script type='text/javascript' src='$url'></script>"; ?> </head> <body> <h1><?php echo $page->title; ?></h1> <div id='main'><?php echo $page->get('outMain|body'); // use outMain if there, or body otherwise ?></div> <div id='side'><?php echo $page->get('outSide|sidebar'); // use outSide if there, or sidebar otherwise ?></div> </body> </html> More than half the time, I'll actually just re-use page variables like $page->body and $page->sidebar rather than $page->outMain and $page->outSide. That way there's no need to consider defaults, since $page->body and $page->sidebar untouched technically are defaults. <?php $page->body = "<h2>{$page->subtitle}</h2>" . $page->body . $page->children->render(); But technically you've got a little more flexibility using your own self-assign anonymous variables like outMain and outSide, so figured I'd use that in the examples above. outMain and outSide are just example names I came up with for this example and you could of course name them whatever you want.