Joss

What, count? Eats into my wine time! All I will say is that the change of one page to another went from okay to not far off instant. With AIOM you notice the load becoming very clean - the code just runs straight through. With Procache you notice the lack of MySQL. ProcessWire has one of the most efficient methods of calling and collating from a database, but is still has to do it - however well indexed. Procache simply takes that out of the process. To be honest, I also have cloudflare in the mix which is helping the images and I have optimized images like mad by keeping the images as simple as possible so they survive squishing. I have learned a lot with this one.

The site I have just uploaded today, http://claysvehiclerepairs.uk is the first site I have done where the pressure was on to speed it up. The site has a lot of graphics, it uses foundation which is far from lightweight, it has 890 or so pages (it has left Pete's sitemap module smouldering), various extra bits of JQuery going on like equal heights and is just big and weighty. I managed to get it running fine, actually, and then I added AIOM and the site shook itself into a higher gear - very pleased indeed. So Thanks to everyone involved with AIOM. Then I gassed up procache, pulled the choke out and hit the start button. The full roar of the ProCache 289 V8 with Holly double pumpers, slot change box and overcharger, thundered into action and the website just about catapulted itself out of the traps and round the internet track at lightning speed. The difference was seriously noticeable. And the result? Page analysis says - &*$£king fast. Mobile analysis says fast too, which considering what is going on is very pleasing. So Thanks to to Ryan for making a CMS that is a joy to optimise with no secret stashes of rubbish to drag you to your needs and for a module that adds rocket fuel to the finished item. Gertcha my son!

Love this from Webmaster Tools: 890 URLs submitted 1 URL indexed. Okay, so a bit of a wait then....

Translation: Cover = Any pub building with a bar roof and alcohol doors. There is a bit of me that would like a mac, but there is another bit of me that does not want another learning curve! There is a third bit of me that has just run and hid my credit card.

Cute!

Oh, give me a break! Do you know how many favicons I already have??? Oh, good - the block idea worked! Actually, I forgot to mention the blocks! Every main page has a single block position and a group of three in a row. I have created about 15 blocks so far and it is just a question of selecting them for a page. With the car pages, since there are hundreds of them, those are selected centrally.

http://claysvehiclerepairs.uk/ A new and very subtle garage website .....not! Clays are a local company and this site is definitely locally aimed. From the technical point of view the website is reasonably brave. The client was keen to list every type of modern car they will deal with and that means almost all of them. I managed to get a reasonably, though not complete list and from that used import pages from CSV to create all the pages for both models and cars. The content for all the pages is centrally generated using lots of Hanna code to insert the manufacturer name and or model name. However, all this content can be overwritten on a page by page basis. Over time the client will be adding his own information about some of the vehicles, especially those he sees a lot of. Service pricing is handled in a similar way. Prices for the three levels of servicing are set centrally but then can be overwritten locally. Generally he says he will use this little as he wants to keep his pricing simple, but the facility is there for him. The site consists of some 980 pages ( a pure beginner in PW terms! ) I have used Lister heavily on this site with most things, including output from the contact form, having a lister of some sort. Hanna Code has been used for the models but also handles all things like phone number, company name and so on, to try and keep consistency throughout the site. Modules used are: Batcher Import Pages Page Field Select Creator Pro Cache (not turned on yet) AIOM Form Builder Hanna Code Color Picker Lister Pro Sitemap Template Notes And a few bits I can't remember! The framework is Foundation 5. I used sass quite a lot here basically to generate my own version of foundation.css with only what I needed. A lot was removed. I have gone a bit mad with the Favicons, using http://realfavicongenerator.net/ Well, they certainly cover everything! The site has been created over many months for non technical reasons, but I have kept it up to date even when it was dormant so that it is running the current version of PW. All the graphics were created in house (that would be me) and my copy of Illustrator has now gone for a lie down. This is a moderately complicated site, allowing for the fact that it offers no functionality for the user other than just reading the site. But I was pleased I could make the site heavily localised and cover everything the client wished with ease. One of his competitors (who also is one of his friends) has a similar idea of a site but built with "another" well know CMS. I won't send you to it - it creaks and groans like a half sunk boat and apparently it is a pig to try and administer and seems to go ape everytime it gets upgraded. So far, the client has been thrilled at how logical the back end of his new ProcessWire website is! There is a lot more to this site than meets the eye, but I am sure you get the general idea!

The words cheap and skate come to mind. Though I believe the northern term for it is "pragmatic"

I have just uploaded a site that has taken months to develop, simply because the client was away for ages. On my local server I have updates the site frequently and it is currently running the newest dev version. Anyway, uploaded, looked at the site and it all works fine. Go to login in the admin and .... WHERE THE HELL HAS MY ADMIN GONE??? Nothing. Nada. zero. Just a blank page. I leap into config and turn on debug and it spits out an error about headers all ready being sent. Just on gut feeling, I replace the config.php file with one from a brand new installation - replacing the database info and the white list. (I forgot to replace the userSuthSalt, but never mind!) And the admin appears and it is all working. So, a warning to all. If you site has been in development for a long period of time, the config file might let you down when you change environments! However, I don't know why......

Morning Teppo! Well, in keeping with the way ProcessWire works this would be pages. So.... Probably the module would include two .md files as default: ModuleName.userdoc.md ModuleName.admindoc.md At install time, these are converted to pages if the docs module is installed. Working backwards... If the docs module is installed later, then it scans the modules directories and adds any of those files. That is the really boring basics. Administrating Docs Since these are now pages, this becomes a little easier. Under Admin in the tree there is a new parent - Docs. Under that two sub-parents - Admin and User. In each are all the relevant pages. Permissions are associated with the admin and user parents which are inherited by their child pages. These permissions govern who can see the docs; by default only admin can edit. Each page has the relevant md file imported into a CKeditor field. This means that the admin can customise the documentation if it is relevant. They can also add extra fields to the templates if they want to change the way docs are viewed. It would be as customizable as anything else in PW. Permissions can be changed for individual pages if there are several roles who need access to different things. Pages can be published and unpublished, as normal, so that if there is no need for particular docs they are not cluttering up the system. Languages If the various module developers are brave enough to do translations of docs, then maybe these can appear on language tabs. Perhaps some markup in the MD file identifies that this next bit is in a different language and what language it is in. A tab is created to match on import. That means the default doc language of the file also needs to be identified, of course. (Bit cheeky to assume it would be English!) Possibly needs the ability for the admin to add their own translations too. So lots of customizable bits there. Because this is the normal page system, the admin can add new pages talking about other stuff. If, for some mad reason, a third set of docs is required, or even a fourth, then another parent can be made - "Authors" or "Telephone Sanitisers" perhaps. Maybe even a publically available parent. Other pages can then be added under there. Viewing Docs The docs module would install its own templates, template files and a unique ckeditor field (so it does not muck up any existing bits). It would install its own search page too. It would show the docs in the language of the setup, if they are available, or it would show the default language of each doc if a specific language is not available. The docs ultimate parent page is the docs home page. It would list available docs on a permissions basis and include search (results on permissions basis). Access to this would be a link on the main menu bar. Linking to Docs This I am not so sure about. if a module has a "settings" page of some sort or some other setup procedurers, it makes sense for the module dev to make sure there are links written into the right part of the docs. The site admin, however, should perhaps have some way of adding links to admin forms to specific help pages. That would be something in the template , I would guess. Very complicated Docs Some docs may be very complicated and should be on several pages. This can use Ryan's multi-page markup system, though it will need something in the markdown doc that it can recognise and convert. So, most of this uses bits that are already available in PW - the biggest bit is the import.

And for the amount of money they charge, you could almost buy a mac!

Seeing Nico's reply in five modules about his default installation,made me think, what does your's consist of? My default profile I am doing has the main modules I like, plus a very basic news system and some SEO fields I have used for a while. In templates folder I have my own SASS arrangement, pocket grid, response.js, enquire.js, respond.js and a few other bits like html5shiv. I have a couple of menu bits half ready to use with Somas menu module. I have a docs folder with all my notes so I dont forget why I have the above in the first place! I have a downloads folder with some jquery bits that are not installed and an elements folder with some layout tests for copying and pasting. It has no templates constructed, but the components are there. So, it really is less of a profile and . More of a kit. A Few More Details The core of what I am trying to do with this at the moment is the CSS setup using SASS. I am only just learning SASS, so this is as much as an educational tool as anything else. My set up is currently this within /site/templates/: scss/ site.scss bourbon/ components/ pages/ site.scss is the main file that imports everything else. This is a lightweight mixin library for Sass. It simplifies working with radients, borders, colours, tints and many other common tasks. Pages will contain any scss directly related to a particular template/page. So, there might be a file in there called _home.scss that has anything extra just for home. Really there should be very little in here, but it just keeps things easy to find. Components contain my main classes, so: _normalize.scss - the scss version _breakpoint.scss - this imports the _mq.scss file. The breakpoints defined in this file correspond to the breakpoints for response.js. However there is no requirement to do this, it is just a starting point. The line $mq-show-breakpoints allows a visual note of the breakpoint in the browsed page. This needs to be commented out on production sites! Ignore the breakpoints at the head of the page _colorscheme.scss - This defines colors for the theme and turns them into variables. Add whatever is required here. _demos.scss - this is for playing around with ideas, often related to files in the /templates/elements/ directory. This needs to be removed from site.scss for production sites. _global.scss - This contains core values that are used throughout the scss system. _layout.scss - this is main layout elements that are reused throughout the site. However, elements that are unique to template/page should be placed in a relevant file in the /templates/scss/pages/ directory. _mq.scss - this is file for sass-mq. The values at the top of the file are overwritten by the values in _breakpoint.scss. _pocketgrid.scss - this is the pocketgrid.css file. Do Not Edit. _processwire.scss - this is for any styles that are specific to ProcessWire such as align image. _typography.scss - All main typographical elements are in here. My top level folder structure within /templates/ is: css - mostly the output of DOCS (all my notes saved as .md and auto converted to .html elements - these are just useful bits. They are not linked to anything and are more a copy/paste library images - well, got to have one, don't yer? includes - a functions file, head and foot if I am doing it that way and so on js - all the js that is not on cdn scss (see above) usefull-downloads - literally a library of downloaded things that will get thrown away on production And then there is the prepros.cfg file, the config.rb file for compass and a couple of templates.

I have been doing something a little similar for myself just using a google site, though I have also started using onenote for bits. Yeah, I know, very un-codey! But I like the notebook/tabs/pages arrangement. Easy to find things.

Just to finish this up - there definitely is a problem, even though I have worked around it for the moment. So here is a careful breakdown of what is going on in case Ryan has the chance to look at it on his way past. Note: please ignore earlier posts in this thread - this is the definitive explanation! Part 1 In a template I have a page field that selects a block from a list of pages stored under a hidden parent away from the main tree. Within the template for the block there is a page field used to select a page to create a link to that page via a button, This is a single select, obviously. I am using a page field here so I can limit what page can be selected. When I create a block, it has an image, some text, a headline and optionally a link using the page field. (if no page is selected, then the button is not shown) Part 2 The blocks are used in two different ways in the most pages on the site: 1. In a set of three using a multi-select and asm. These appear in a nice little line - how cute. 2. As a single select in a different part of the page. The multi select generates no problems at all. Part 3 With the single select, everything is fine until, within the block, I choose a page link (using the page field) that is within the same part of the tree as the page within which the block will be displayed. To make it clear, here are two parts of the site: servicing --- Little Service --- Big Service repairs --- brakes --- exhausts (Note the site is actually more complicated than that, but I don't want to bore you!) Lets say that we create a block about brakes that includes a link (using the page field in the block template) that goes to the brakes page. On the Little Service page, I now select that block using a the single select page field. The block displays fine. On the exhausts page, I select the block using the single select page field It throws a 500 error. And that is it. My current work around is that I have made the single select field into a multi with ASM and put a note that only the top most block will be used. I have used first() to retrieve the block in the template. That does not break it. I have tried both types of single select by the way. I haven't a clue what is going on!

Which is why I said you should use an equal heights system above. That way, they are neat, fit properly and you are not constrained by how much text you use. You could also look at a solution that Pocketgrid uses that might work with bootstrap http://arnaudleray.github.io/pocketgrid/examples/fix-for-different-block-heights-nthchild.html Edit: the advantage of using equal heights, by the way, is if you have borders or background in your blocks, then with equal heights everything lines up.

You can get lotion for that.

Sorry, just trying to be helpful. Why are you having to create new rows in the first place? You can just do a whole load of divs and they will wrap themselves with bootstrap based on what ever column width you have set. That means they will wrap at different points depending on your classes. See here. http://www.bootply.com/70929

Pocketgrid is one. And any that work on a block method rather than a strict row method You will like how complicated the code is in the css

The bootstrap code needed is here: http://getbootstrap.com/components/#thumbnails I assume they automatically move onto the next row? I am sure they used to in the earlier version of Bootstrap using UL I would not rely on img-responsive, however, as this means you get squished images of potentially different shapes. You are better using processwire size() to create identical sized shapes to start with. Using things like response.js you can even call different sized images for different media queries so you always have the right image. You might also need to make sure that columns are of equal height and there are several good plugins for JQuery that do that like: http://brm.io/jquery-match-height/ This sort of thing is an awful lot easier with some of the newer frameworks, I am discovering.

Actually I had forgotten about that till after I wrote this and it does actually address a lot of the issues. Though, it is one of those odd things that sometimes it is nice to look at a list.

I just noticed that this lonely little post did not have a reply So, Ryan, when you posted this topic back in 2010, did you know what a huge can of process-worms you were opening?

That is the beauty of ProcessWire - you can do so much without a single extra module if you really want to. But I think the five that I tend to add first are things like: XML sitemap Hanna code (I use it loads) Procache Lister Soma's Help notes thingy

Just a very vague idea here. The idea is to create a set of help pages in the back end. Not the wonderful notes system from Soma (which is ever useful), but a centralised system that is partly automated. So, for each module two sets of docs are written by the developer - admin and user. When a module is installed, these are automatically added to the backend help system. This is permissions based, so the superuser can decide who can see which set, plus make exceptions for specific modules. This includes switching some of the docs off entirely if it is thought they might confuse or are simply not needed. (Might even allow devs to pre set this if their mod adds functionality where docs are unlikely to be needed) Additional notes can be added manually to each of the docs at either the head or tail so the admin can add anything specific to that particular website. When modules are updated (which might include updates to their docs) these additional notes are not affected and still work. Extra docs can then be added by the admin for site specific functionality that are not related to a specific module. The entire lot can be viewed in the admin as a cohesive set or can be viewed as in context help in a popup. Sorry! This system does put a pile of work on module developers (and even more on Ryan), but the result if worked out properly could help the day to day usage of the admin enormously and makes ProcessWire even more accessible to potential clients The two sets are key here. On other systems where help is built in, it is often aimed at the admin not the user, so the poor user gets flooded with information they might not understand and do not have the permissions to use even if they do. This way, each user, admin or other, just gets the bits they need which is a lot cleaner!

Might be...... Even in the corporate environment with products, being able to list and relate to products in different ways that does not always repeat the same formula surely must enrich the site for customers. Might be good for SEO too, I suppose (I have no evidence for that in any form whatsoever!) As for photos, though I do a lot of photography and love it, I am a word man first. I work on the principle of: "If a picture paints a thousand words,,,,,," Then its a pity they are not searchable!

Just added a comment or two about installation