Joss

On the other hand, this is quite cute: https://github.com/guardian/sass-mq From those nice people at the Grauniad (for those Britons old enough to remember the joke)

Okay, starting my learning curve and currently it has flipped all the way over and banged me in the back of the head. Its working okay, but currently it is messy. My main issue is handling media queries. I don't particularly want to nail myself down to set breakpoints, but it is as good way of learning. I have found some code to give them names using maps, but I am worried that I am going to be generating a lot more css code by doing things like .my-class { color: red; @include respond-to(small){ color: blue; } Than in grouping media queries together.

Or even: <!-- Diogo says that I should tell you that this bit of code is to do with that very nice EMO module, okay? -->

I already use Prepros for compiling sass and less (and minimising and squishing) and have used it with Foundation without issue. I have rubygems installed on my dev box and can install boubon mixins from there. So, all of that is set up and happy. It is just a question of finding time to learn it! What is available for ST3? Other than a syntax highlighter, I haven't looked further.

Are you using email obfuscation? That script is the email obfuscator doing its job.

As far as I am aware, Google definitely don't use Meta Keywords, Bing definitely doesn't and it looks like Yahoo don't either. Keywords are also a lovely way of telling your clients' competitors what words are important to your client. I use them all the time - reading them from the competitor's website.

Its down to me finding time to learn, really. The list of things to learn is getting depressingly long.....

Okay, Mr Knight. I haven't done a graphical mockup, but I have worked it through in a more logical way: Allowing the selection of a parent for a field on creation of a child page. The system is allied to the Add New tab and allows the user to choose the parent of the new page within the hierarchy defined by a predetermined list. Template Family Tab One or more parent pages can be selected on a template being used for children. Allowed Parents Three choices: ASM Select - choose specific pages ASM Select - Choose pages who's templates are - select one or more templates Field - any other select criteria for parents using normal select syntax. If any one or more of these are used, then when you create a page of a specific type from the Add New button, the drop down is shown on the initial create form, but the value can be edited in the Settings tab. Only one parent can be chosen in this default state. However, if parents are being used as categories and the post needs to be associated to more categories, then this can be treated as the primary category and the others can be added, perhaps, using a page field as normal. Settings Under settings there would be a new area where the dropdown is repeated. This allows the choice of parent to be changed. However, this action would actually move the page in the Pages Hierarchy. Are there any checks that should be made that might prevent this from happening? Lister Configuration I originally suggested this should also be part of the lister configuration for the lister Add New button, but this is a bad idea since depending what the list is, the pages might be from more than one template. However, if you do Add New on a lister, and the template of the new page has the above setting, then that would override the Parent setting on the lister configuration. Multiple Templates More than one template can share parents with this system. You may have several templates with access to the exact same set of parents, or with overlapping selections and so on. There is no reason to limit this. However, if a parent has set templates that can be used for children, then that parent-template combination cannot be chosen by other templates. Limitations There is a problem if a child page is created in such a way as you have a choice of templates. There is two ways around this: Like the current add new system, limitations are attached to make the system work. So, the templates of all potential parents must have only one template possibility for child pages, and it must be the same page. The create page dialogue comes up as at present. When the template is chosen, a check is made and if the chosen template is to be used in this way, a new field is opened with ajax with the choice of parents. Selecting one would be required. I think the second is a better choice simply to cover combinations of familial relationships which are not predictable and to allow more than one template to be used for the child. For instance, if this is a news service, then you may have different templates for reviews, recipes, politics, and so on.

Is that a dance track?

There is an autosave module kicking around that Soma did. Never tried it in combination with dependancies - http://processwire.com/api/selectors/inputfield-dependencies/

I am sure this has been talked about before - but never mind, here goes! A configurable single select drop down field where you can chose the parent of a new page. This is aimed at two uses - the Add New button and Lister. So, you have this structure in pages: Home --- News --- --- Cat 1 --- --- --- Post 1 --- --- --- Post 2 --- --- Cat 2 --- --- --- Post 3 --- --- --- Post 4 --- --- Cat 3 --- --- --- Post 5 --- --- --- Post 6 Post all have the same Template Cat all have the same Template In template settings for Post, you would be able to say that it could have three parents - Cat 1, Cat 2, Cat 3 So, this would not be allowed template for parents, but allowed parent pages. A check box might say "Add this as a field option" If that it true and the add to add new button is true, when the Add New button is clicked, the resulting new page form has two fields - Title and a Parent select. Within Lister, a similar thing becomes possible where you can select more than one parent page. This only has certain uses, but it does encourage the use of the page hierarchy which is good for sitemaps. Getting Clever - or too clever! However, it might need to get a bit more clever. So, for instance, you might be able to select: "Automatically add new options based on template." This means, that as more categories are added to the above scenario, then the parent list automatically updates. Perhaps you can do both options at the same time: Select specific templates for potential parents Select specific pages for potential parents The difference is that if you have templates called Blue Categories, Red Categories, Basic Page, and you want all pages in Blue and Red to be parents, but only 1 specific page from the basic-page template to be a parent, that can be set up. Getting way over clever There is a further mad enhancement using dependencies. Let us say that you have several levels of categories starting with three main categories, Red, Blue, Green You select on of those as a parent to create the page, but once you have, you then have a required (optional) Parent Field in your template which chooses a sub-category based on the initial selection. Once that is chosen, if there are sub-sub categories, then a new field appears with these. And so on. You can drill down your complicated catalogue, if that is a good way to do it for your site, and retain the page hierarchy. You could also do this as a single drop down on the page create dialogue where the dropdown shows the hierachy as a list, with parents also displayed so you can see the relationships: Blue Blue > Shoes Blue > Shoes > Women's Multiple Categories This only works with single categories since a page can only have a single parent, obviously. However, there is no reason why you could not add a normal page field to add cross relationships, though I suppose it would be nice for this to exclude the parent page from the list - might be a bit too, too clever that one!

I think you are misunderstanding how ProcessWire works. The reason Drupal has content types is because they welded a CCK on top of the system as an after thought. ProcessWire has no such restrictions. You create dedicated templates for everything. You want a review page? You create a template for it. You want an event page? Create a different template - and so on and so forth. In fact, you HAVE to do that - the blank install has nothing in it. It is a blank sheet of paper for you to play with. Systems like Joomla and Wordpress are not really Content Management Systems - they are Article Management Systems which have to be bent to work with different types of content. ProcessWire is a true content management system in that is manages any kind of content that you want to create. Pages, as I said before, are whatever you want them to be. They are not a limited thing like the mainstream Drumlapress. They are just what you create from whatever template you design.

Fair enough - I have, ummm, other things to do right now anyway....

Do you mean viewing for unpublished or restricting viewing for published? (Subtle difference here... ) (And I am still enjoying this wonderful Rioja!)

Okay, I have a template called image.php that is used for creating a page with a single image and things like description and a load of rubbish. However, these pages are really there to make up a gallery using Page Table Extended - but they have their own template file so they can be seen outside of the gallery on the site. Nothing complicated. The template had headers and footers and tons of rubbish that is no good for page table extended, so have I use your thing: <?php if($options["pageTableExtended"]){ /* The gallery images are used in a page table extended in admin. We cant display those with all the head and foot! So in this section we do an alternate markup */ echo "<h3>{$page->headline}</h3>"; } else { /* Back to the normal markup */ include("./includes/head.inc"); include("./includes/scripts.inc"); include("./includes/foot.inc"); } But, when I go and look at the page in the admin that used the page table extended field, it does not display the headline, but just the error as above. I haven't added all the other fields yet, I am keeping it simple just to get it working. Boy, this rioja is good!

Oh, damn - I am going to have to go back and look. I have been working on some D&B arrangements and got sidetracked (at my age too!)

A page isn't anything - it does not exist. It is only the result of a template - and you can create as many templates as you want. And templates only have to have associated files with them if the resultant pages are being rendered - because you can pull the contents of fields into any template from any other page created with any other template. So, a page is not a base content type at all - there is NO base content type, you have to create them. For more on pages see this old thing: https://processwire.com/talk/topic/2296-confused-by-pages/

Is this selection for use in the backend, in the admin, or is it used in the front end? If it is the front end, then the place for the logic is in the template file - that is what it is there for.

Just to keep you at ProcessWire before in you end up in the Mire of Drumlapress, if you are happy to learn, the PW is really not a bad place to do it. The problem with the others is you will put a site together but you will not learn a thing. However, I can be of a little help here: http://processwire.com/docs/tutorials/but-what-if-i-dont-know-how-to-code/ Now, this starter is not teaching you about html and css, but to be honest there are thousands of great resources out there that will get you started very quickly. However this tutorial is aimed at anyone who hasn't done a thing like this before. It is long-winded and detailed, but I have tried to keep it fun and explain EVERYTHING. So, go and play. PS: I suggest a jug of strong coffee to go with it.

I like Foundation, more than I like Bootstrap, but I have ended up in the same place that brought me to ProcessWire in the first place. With Drumlapress, I felt hogtied; I had to work the way the system wanted me to. Attempts by people like Seblod to make Joomla, for instance, more manageable, just ended up as bloat - one huge system glued on top of another huge system and I still wasn't close to what I needed. ProcessWire was a relief because, at its most basic, it allows me to put any content I want into a page and manage it from a backend - and that is it. Likewise, working with Pocketgrid, Simple Grid and the other minimalistic approaches means I am freed from a straightjacket - I can happily wander off and make my own mess, not wallow in someone else's.

Playing with pocketgrid is interesting. Since there is no grid system within it, you just throw percentages at it and play with blocks, that really frees up the thinking. The media queries above are just ones I have worked out thinking about target audience - I know at some point I have to fit into that space in one way or another. Whether I use one, none, all, or add some specific ones for one little bit, is another thing entirely.

And that was the difficult bit!

Yeah, Ivan - I have found that with both Foundation and Bootstrap. I have a kindle fire HD with a 7" screen and using the standard breakpoints really doesn't take advantage of the screen size (or lack of it). And Amazon sell a LOT of them! Content should determine breakpoints, but it is useful to have a starting point. The interesting one is with response.js - you can create tests that use height, width, pixel radio, or even a mixture (though I haven't worked out how yet). Although the risk is that you make too much work for your self, you can set up some interesting parameters, and then use fluidity within those. Bends your brain, though.

I must, at some point, sit down and learn sass. My brain seems resistant to it, for some reason.

I am enjoying the very basic grids. My main reason is a wish to only load the things I want when I want. I was doing that with Foundation (not using the min versions, but only loading components) but it was still a little heavy. Also, I am trying to search out JQuery snippets to do little things rather than use something that does more than I want. It just feels easier to control. I doubt I will never get to the stage of writing my own slideshow, but all the other small things I hope to cover. It is one hell of a learning curve, however!