Leaderboard

Just finished our companies new website build with Processwire. Main site: http://www.agrio.nl/ A few branding pages: http://www.vee-en-gewas.nl/ http://www.melkvee-magazine.nl/ http://www.agriomediaplanner.nl/ fully responsive pro-cached several "one page" pages for each section / brand unique structure with templates as building blocks Our companies home page structure is shown in the attached screenshot. It contains several templates used as building blocks. The goal was to have a reproduceable structure and design to be able to easily create new landingspages without the need to code anything on the front-end level. An additional benefit from this structure is the posibility to give content editors only access to the content templates (orange coloured). Another thing to mention is the shared (green) pages, which contains content that needs to be re-used on several places in the website. For example the footer contact and google maps. But also structures for certain content.

This tiny module is intended as a helper for Ryan's Hanna Code module by providing a way to select existing Hanna Code tags within the editor. This is something I felt our clients needed in order to start properly using Hanna Code tags. See attached screenshot for details -- there's really not that much to it at the moment. Each editor requires it's own plugin and currently I've only cooked one up for CKEditor, where the plugin presents itself as a context menu item (visible on right click). I'm planning to expand the feature set of that one slightly and then probably convert the CKEditor plugin to TinyMCE, but that's just about it. Ideas are welcome, though. Some of the code is pretty much duplicated from Ryan's original module. I hope he doesn't mind -- though for the record I've also tried to make it very clear in the source what part that is and where it's from.. GitHub: https://github.com/teppokoivula/HannaCodeHelper Modules directory: http://modules.processwire.com/modules/hanna-code-helper/

Hi Felix, hi everybody. Long time no see! I have mixed feelings about this idea of pimpin' up PW's backend. Currently PW doesn't make many assumptions about previous expertise of the developer who uses it and requires very traditional skillset apart from jQuery which knowledge is de-facto standard for any front-end developer. And this fact is the key concept that makes PW open and friendly for everyone. The thing is, people still can use BEM OSCSS or whatever they want if they build with PW as it's a framework as much as it's a CMS. You can use existing backend and build on it or even start from scratch if needed. You can use any framework but you're not forced to do it. I don't think current default back-end needs loading optimization at the moment. PW has one of the fastest backends I've ever seen. IMO, optimization at this point would be premature and profit would not be worth the effort. BEM and OSCSS (don't know about SMACSS) are templating ideologies aimed mostly at large projects with big dev teams. Yandex, the largest Russian search engine company (kind of little-scale Russian Google) who invented BEM, use it in their projects because they need it for their very complex and unique projects. They wanted to shorten render time of their interfaces in (mostly) older browsers and to standardize the way their teams worked. These problems are very rare for most projects. So modular CSS, IMO, is a marginal demand. MODX made a big mistake putting their chips on ExtJS in the back-end of Revo branch. They lost many loyal devs since then. Partly because this framework was marginal at the market and its learning curve was steep. Let's not step on the same rake. Not sure but I guess modular JavaScript could be added optionally via a module. The strength of PW is its openness to any developer and, I dare to say, any user. It was a relief for me to see PW's interface. I'm not sure PW has to compete with these systems as (for me) it already has a better interface. Less noise, less distraction, less confusion = more focus, more flow, more get done. Accessability is a good point. I think this kind of interface extension could be implemented as a module. Btw, I believe BEM and semantic markup ideologies are not compatible As far as I know there is a project for core testing in PW, but not sure if it's active. Ryan can tell for sure. I'm inclined to think that PW's default backend should stay as slim as possible in terms of dependancy on third party frameworks and concepts but be as extensible and hookable as possible. Every new "hard-coded" concept or framework will bring new element of complexity to a system, make it more closed, and make learning it more difficult. All these features proposed here are really great and PW will definitely win more developers and users if it implements at least some of them. But, IMO, they have to extend or override PW's defaults not substitute them. Another way is to start an alternative backend project that would embody the latest tendencies of front(back)end development and help make some hype in more visually-oriented and framework-aware crowd.

This module is obsolete - please use the Console Panel in Tracy: https://adrianbj.github.io/TracyDebugger/#/debug-bar?id=console Ok, this is really not very fancy, but I think it will come in quite handy - for me at least It provides an admin page where you can test code without the need to edit template files. It runs from a new item under Setup called "Code Tester" Simply enter your code, including an opening <?php and click "Run Code". Page will refresh with the code block still in editor, and with an iframe containing the results of your code below. In some cases the output may not be relevant if your code is manipulating pages etc via the API, rather than outputting content to a page. Then you can easily make code changes and run again. Github: https://github.com/adrianbj/ProcessCodeTester Installation Install as normal, then move the included file "code_tester.php" to your site's templates folder. Depending on your sites template structure, you may want to edit this file. I have set it up using the head.inc and foot.inc approach that is used in PW's default profile. There are detailed instructions in the file to make it easy to modify as needed if you prefer using a single main.inc or other approach. Install the ACE Text Editor module if you want syntax highlighting. That's It! How it works Nothing very high tech - when the module installs it creates a new template: code_tester and a new unpublished page: Code Tester. When you click "Run Code" it creates/updates this file: /site/assets/files/ID_of_Code_Tester_page/code_tester_code.php and writes your code to the file. This file is included from the code_tester.php file and the code is run and the output processed. Note that I am using ob_start(); include; $out = ob_get_clean(); so that this will work take the approach of populating variables that are output within a main/shared markup file like main.inc If you want to use a variable other than $out in your test code, you will need to edit the code_tester.php file accordingly. Things you can do It may not be immediately obvious as to some of the things that work with this, so here are some examples: echo 'test'; $out .= 'test'; //list page titles matching the selector foreach($pages->find(selector) as $p) $out .= "<li>$p->title</li>"; //populate the results frame with the page returned by the selector. You must use $getpage as the variable! $getpage = $pages->get(selector); // bulk delete pages matching the selector foreach($pages->find(selector) as $p) $p->delete(); So really it is more than a code tester - it can also be used as a way to test selectors and return the resulting page and also as a way of running admin maintenance scripts. Hopefully you guys might find it useful. Please let me know if you have any thoughts for improvements.

Your both right. When rescaling the window some divs around images are hidden (bootstrap 3 hidden-xs for example). But also jQuery takes care of some of the background images. I'm using data-bg-big and data-bg-small with both an image URL the latter one is resize a bit smaller. Then with some jQuery throttle function at resize checking every 250 ms for the window size. Depending on the size i show the big, small or no background image. So if you are on any screensize < 768 the background images never gets loaded. You are right about that, this is something i still have to do. Didnt had the time to finish it all before the deadline. The meta description tags are going to be filled as we speak.

Nice looking site and a lot of content. Impressive. Looking at the html source there are a lot of css files. It probably would be better to concatenate some of those files, especially for mobile performance. Also, the meta description tag is empty. Is this intentional?

What does autojoin do? Using the 'autojoin' optimization can increase performance on fields that get used a lot. Not using it can reduce the page's memory footprint. What is more desirable in each instance depends on your situation. What sites should use autojoin? Autojoin is most applicable with larger sites. On smaller sites, there may be no benefit to using it or not using it. But it's good to know what it's for regardless. Where do you control autojoin? Autojoin is controlled per-field. You can turn it on by editing each field under Setup > Fields > [your field], and you'll see it under the 'Advanced' heading. When should you use autojoin? Autojoin causes the field's data to be loaded automatically with the page, whether you use it or not. This is an optimization for fields that you know will be used most of the time. Fields having their data loaded with the page can increase performance because ProcessWire grabs that data in the same query that it grabs the Page. Autojoin is a benefit for fields that are always used with the Page. This is best explained by an example. Lets say that you have a template for individual news stories called news_story. The news_story template has these fields: title date summary body sidebar We'll assume that when you view a page using the news_story template, all of the fields above are displayed. Fields that should have autojoin ON: Now consider a separate news_index template that displays ALL of the news stories together and links to them. But it only displays these fields from each news story: title* date summary In this case, the 3 fields above would be good to autojoin since they are used on both the news_index and news_story templates. If your title, date and summary fields didn't have autojoin turned on, then ProcessWire wouldn't go retrieve the value from the database until you asked for it it (via $page->summary, for example). Because the news_index template displays all the stories at once, and always uses the title, date and summary fields, it will perform better with title, date and summary having autojoin ON than with it OFF. In this case, it reduces the query load of the news_index template by 3 for each news story. To take that further, if it were displaying 20 news stories, that would mean 60 fewer queries, which could be significant. Fields that should have autojoin OFF: Now lets consider the body and sidebar fields, which are only used on the news_story template: body sidebar It would be desirable to leave autojoin OFF on those fields because there is no reason for the body and sidebar to be taking up space in memory when they are never used on the news_index template. While it might mean 2 fewer queries to view a news story, that is not significant and certainly not a worthwhile tradeoff for the increased memory footprint on the news_index template. Keeping autojoin OFF reduces a page's memory footprint. Conclusion Using the 'autojoin' optimization can increase performance on fields that get used a lot. Not using it can reduce the page's memory footprint. What is more desirable in each instance depends on your situation. But if your situation doesn't involve lots of pages or data, then you don't need to consider autojoin at all (and can generally just leave it off). Additional Notes Not all fields have autojoin capability. You won't see the option listed on fields that don't have the capability. *The title field has autojoin on by default, so you don't need to consider that one. It was included in the examples above because I thought it's omission might cause more confusion than it's inclusion. Be careful with multi-value fields that offer autojoin capability (page references and images, for example). Because MySQL limits the combined length of multiple values returned from a group in 1 query, autojoin will fail on multi-value fields that contain lots of values (combined length exceeding 1024 characters). If you experience strange behavior from a multi-value field that has autojoin ON, turn it OFF. If you want to play it safe, then don't use autojoin on multi-value fields like page references and images.

Here is our website using ProcessWire, still work in progress: http://www.mokkivertailu.fi/ The site is a search engine for rental cottages in Finland. Cottage owners can register and add their information while users can search and browse the database.

Hey guys! Another tiny little PW site we have built in the last few weeks. Really really reaaaaaally small budget, so nothing is really perfect on this website. But the client (a friend of mine, he is a teacher and a hobby author) is happy to now have more control about his content, speaking of his short stories and novels. See for yourself - feedback welcome: http://www.peterhohmann.net

If I'm not mistaken the design of the WP admin is from Jason Santa Maria. Couldn't be ugly for sure...

Definitely the sessions. I don't think theres any use in copying those. Same goes for db stored sessions. Apart from that i can not really think of a lot of unnecessary stuff. If you use caching you can safely omit the cache files as well (i think)

The first instance of the Cache-Control headers is from a session_start() - it's not Processwire per se, it's PHP initializing a session. http://www.php.net/manual/en/session.configuration.php#ini.session.cache-limiter EDIT: You may be better off only modifying the caching on css/js/images and letting the html pass unmodified - especially when a session is active. That can be done with a FilesMatch wrapper similar to the one used prior: <FilesMatch "\.(jpg|jpeg|png|gif|js|css)$"> <IfModule mod_headers.c> Header set Cache-Control "max-age=7200, must-revalidate" Header unset Last-Modified Header unset Pragma </IfModule> </FilesMatch>

Wow! Super nice design! Excellent work.

Thanks for trying

Some projects i have used SCSS, just not in this project. Maybe if i can find some spare time the normal CSS could be converted to SCSS. But for now im using my colleges Martijn his Markup CssCompress module, that works great too. http://modules.processwire.com/modules/markup-csscompress/

If you use SCSS, you can combine and minify as you build.

Way simpler than that, the background is changed in a CSS media query, if I'm not mistaken

Nice! I especially like the way the responsiveness of the layout is achieved, the way the background images appear or disappear instantly on resizing, not just with a reload - taking a quick look at it I think it´s done with jQuery, right? really nice...

Lovely responsive layout, and also a great example of yet another way to structure content in PW.

Hey people, at last found the solution (getting width and height attributes for img tags into HTML created with CKEditor) : In /site/modules/InputfieldCKEditor/ckeditor-4.1.2/ changed config.js from: /** * @license Copyright (c) 2003-2013, CKSource - Frederico Knabben. All rights reserved. * For licensing, see LICENSE.html or http://ckeditor.com/license */ CKEDITOR.editorConfig = function( config ) { // Define changes to default configuration here. For example: config.language = 'de'; config.uiColor = '#FEE673'; }; To the following (explanation in the comments): /** * @license Copyright (c) 2003-2013, CKSource - Frederico Knabben. All rights reserved. * For licensing, see LICENSE.html or http://ckeditor.com/license */ /** * ...finally found out how to force CKE to output attributes instead of styles for img width and height: * * Important: additionally to adding everything form "CKEDITOR.on('instanceReady', function (ev)..." onward * also the line "config.allowedContent = true;" needs to be added or else it has no effect! * Joe */ CKEDITOR.editorConfig = function( config ) { // Define changes to default configuration here. For example: config.language = 'de'; config.uiColor = '#FEE673'; config.allowedContent = true; CKEDITOR.on('instanceReady', function (ev) { // Ends self closing tags the HTML4 way, like <br>. ev.editor.dataProcessor.htmlFilter.addRules( { elements: { $: function (element) { // Output dimensions of images as width and height if (element.name == 'img') { var style = element.attributes.style; if (style) { // Get the width from the style. var match = /(?:^|\s)width\s*:\s*(\d+)px/i.exec(style), width = match && match[1]; // Get the height from the style. match = /(?:^|\s)height\s*:\s*(\d+)px/i.exec(style); var height = match && match[1]; if (width) { element.attributes.style = element.attributes.style.replace(/(?:^|\s)width\s*:\s*(\d+)px;?/i, ''); element.attributes.width = width; } if (height) { element.attributes.style = element.attributes.style.replace(/(?:^|\s)height\s*:\s*(\d+)px;?/i, ''); element.attributes.height = height; } } } if (!element.attributes.style) delete element.attributes.style; return element; } } }); }); }; That does it, problem solved! It just seems that img width and height attributes make images load faster than putting them in styles, so this is what I wanted to do here. Found the solution here: http://ckeditor.com/forums/CKEditor/Forcing-img-tag-to-use-width-and-height-attributes-instead-of-style in combination with the hint from dragan in: http://processwire.com/talk/topic/3972-ckeditor-with-attritbutes/?hl=ckeditor I´m sure there might have been other solutions, like switching to TinyMCE or re-writing the CKEditor-created field content in the page´s template file as I wanted to do at first, but this seems to work nicely and so I´ll stick with it. Thanks everyone for your help!

I'm a bit hesitant to post this site but here we go: http://wereldburgersgroningen.nl/ For the non-dutch: a site for a soon to be opened hamburger restaurant in Groningen, the Netherlands. The interior has a clean/industrial look with some Mediterranean elements/colors. For this small site I was on a real time-crunch so it's still a work in progress. There's no caching or other optimizations (i don't think this will be necessary for this small scale site). It should be mobile friendly but haven't had time to test it on a lot of devices. The most important part, the menu, is still missing. Also, if you're looking for some nice imagery of the place and/or burgers you are out of luck. This needs to be incorporated when stuff becomes available. For me this is a new hosting provider so i'm curious how the performance is for you guys. For me it works pretty fast. It runs on the DEV branch. I'm quite enjoying the new admin theme. edit I've had some discussion about whether there should be an explicit home link in the navigation or not. For me it's second nature to click/tap the logo but i'm wondering if this is intuitive for most people?

Macrura has a good suggestion. You could something like this: <?php $fieldtype = "FieldtypeText"; $ts = array("home", "basic-page"); $fields = "test1, Test 1, This is a first test creation test2, Test 2, This is a second test creation"; foreach(explode("\n", $fields) as $field){ $f = new Field(); $components = explode(",",trim($field)); $f->name = $components[0]; $f->type = $fieldtype; $f->label = $components[1]; $f->description = $components[2]; $f->save(); foreach($ts as $t){ $template = $templates->get($t); $template->fields->add($f); $template->fields->save(); } } You can place this is a template file, or to make life easier, you can simply paste it into the Code Tester module or the Hanna code module (using the code test functionality), which makes it super quick and easy to run the code whenever you want. All you need to do is worry about the editing the $fieldtype, $ts (templates) and $fields variables - you should leave the rest untouched. Each line in the $fields string is a new field with the components being: name, label, description This will create all the defined fields and automatically add them to all the templates you specify in the $ts array. Hope that helps - let us know if you need any help with it.

also i think there are some code examples in the forum for how to add fields using the API; you would just paste that code in a template file and run it and all your fields/templates would get created... will have to search tomorrow...getting a bit late here

Is there a way to set permissions for some page and children if they are using some common templates, or we need to use different set of templates for that section and set the permissions to them? Is there some workaround? Best regards!!

I have to say I agree a lot with what Felix is saying here, though I sure our methods would differ in some ways the overall message is the same, the admin interface is holding PW back. While the new design is an improvement (for the most part) it really doesn't hold a candle to Ghost, Craft, Statamic or even WordPress, and I feel like this is at an extreme odds with how the API its self functions which is clean, modern, easy, concise and beautifully self apparent. Some of the other things mentioned here I have mention before as well, a more modular approach, fixing the massive overuse of !important, migrating away from jquery ui (its antiquated, bloated and generally looks like shit, sorry), adding font icons (in the new default! yay!) so on. I believe PW can dominate if its gets the "sex appeal" it sorely needs and frankly the new theme still isn't going to get us there, not yet at least.

The LanguageSupportPageNames on dev core (2.3.5) is much farther along (and more stable) than the one on stable core (2.3.0). If you want multi-language support, you would benefit a lot from using dev. There are still bugs being worked out here, but most of them are ones that only affect Soma and his advanced usages but they are all issues that will be fixed before dev becomes the stable 2.4.

So if I want to use stable Localized page names (mind you, not latest, but stable and ready for production), I should go for the dev, right? (2.3.0 has localized page names marked as 0.0.3 – not Ready f/ Production)

Pete already said it well, but I'll put it another way too. URL segments don't have anything to do with queries or filtering or anything like that (unless you choose to make it do that with your own code). They are just something your code can look for to do something, like Pete's example above. It's no different than checking the value in a GET or POST variable for instance. The benefit of using URL segments over GET vars is that the URLs look prettier (and probably more search friendly), and they are cacheable.

Diogo's right of course, there's already front end stuff in the admin but it's fairly conservative. Separation of duties between the core admin and a more frontend focused fancy tool could allow the core admin to be even less dependent on third party tools, the ebb and flow of UI trends, etc. I'm not taking a Luddite stance, I'm just thinking that anything so cutting edge as to be like Felix said, "applying all possible developing and design good practices" will forever be in Beta but we'll always need a stable, solid, easy to support and troubleshoot admin tool. These are two different requirement sets. Felix, it sounds great and I don't have anything against the tools. I brought up the observation about PW leaving frontend out of the framework (which we both like) to support my reasoning which goes something like... Admin pages with state of the art bells and whistles have lots of frontend. Frontend is not baked into PW, for good reason. Therefore this new cutting edge admin thing should not replace the standard PW admin system we depend on. Having it separate would take some feature creep pressure off of Ryan. Standard admin could be as "pure" and failure proof as possible. By separating these two admin interfaces they are each freed from having to meet criteria which pull in opposite directions. (fixed a typo)

I think that you have to use something like $today = time(); or format $Dated with strftime() and $c->getUnformatted('Dated') with your formatted $today var.

http://www.michael-wessel.de/ - the website of a german IT service provider - is now powered by processwire. By the way: Some of the most recent work of the agency i work for is and (most likely) will be done using processwire. Me and my colleagues (some of them are registered here, also ) are pretty excited about it's speed, simplicity, community, ease of use and last but not least: the awesome API. So: Expect some more examples (as well as plugins and admin-themes) to come! Best regards Felix

Looks cool Jonathan! I look forward to taking a closer look soon. In reading the notes, I noticed what you said of head.inc/foot.inc and just wanted to mention that most of us don't actually use that method. It's just what it is in the default profile purely because it's the simplest for newbies to understand (and most similar to the WordPress approach). So the use of head.inc/foot.inc is really more about making things easy to understand and a gentle introduction, but it's probably not the way to go as your needs grow. I also noticed that you use _init.php – is this related to ProcessWire's _init.php using the $config->prependTemplateFile and $config->appendTemplateFile options, or is this something different? I also see in your API methods addStyles/addScripts -- do these use the $config->styles and $config->scripts or is this something different? Maybe I will find my answers when I get more time to explore the module. Thanks for your work and sharing this with us.

I found it pretty logical (but not common). It divides two groups. Not intended to use between each element. If you want divider between each nav element, then just style it.

Hi, Not answering your question...just a comment/rant at Foundation CSS. <rant>I use Foundation myself and I didn't know about this. What an absurd way of creating a divider effect!! </rant>

Just a little hint: in config.js, you can add these lines: config.allowedContent = true; // don't filter anything, i.e. allow custom style / classes / id etc. config.enterMode = CKEDITOR.ENTER_P; // by default, CKEditor wraps everything in DIVs - annoying. This will wrap everything in <p> tags