Pete

I like both of those. I'd seen Cloudflare a while back but never read enough to understand what the benefit was. Okay, so you can minify your JS and CSS yourself relatively easily enough, but one of the things Cloudflare seems to do is do it for you, as well as hosting all your JS, CSS and images in geographical areas closer to the end user. Whilst I agree there would be little point for most small sites, one site I have has over a hundred articles and most of them have screenshots with them. The new version of the site will also be a bit graphics-heavy in terms of the design. Therefore I can see the point there as you don't want a gallery to take a while to load and then have to wait ages from clicking on a thumbnail to seeing the larger version of the image. It does look like it could take some tweaking though so it doesn't cache things you don't want it to. New Relic also looks excellent for a different reason - if it works as per the video then it can help point out performance bottlenecks based on what content people are viewing most That certainly sounds excellent and takes a lot of the guesswork out of troubleshooting what can often be annoyingly hard to find issues. Kudos to both companies for providing a free version, though I can't immediately see what New Relic's free version offers.

I think something like what you've linked to there diogo may already be on the cards for the future. I do really like how they've laid that out over at Symphony so maybe something similar to that would be good - I do like the way I looked at the page and thought "yep, that would be pretty easy to do in PW" and already had myself thinking about the code behind it. Definitely makes a change from other systems I've used where it would be more a case of "I wonder if this is possible?"

That's kind of what I'm trying to do, but hide the thumbnail links when they're not needed to avoid confusion - that's what this next bit of code would do

I've seen that sort of thing too Antti with an online shop - they had folders A-Z with each page storing files randomly in subfolders inside one of the letter folders, but your example is much better as it allows to scale a lot further, is far more logical and is a lot easier to program (I don't mean that this would be easy to implement, but it removes the random element I just mentioned in the other software I'd used). ryan - Antti's suggestion above does make a lot of sense although it sounds a bit crazy if you've never dealt with that many pages before, but even if you were getting to a more comfortable 20,000 pages it would make sense. I think the thing to think about with this many pages is how various programs interact with files and folders. There are a lot of different web server setups that can run PW, but they probably all have some sort of limit in this regard which you can safely assume will be different, so something like Antti's solution makes sense to me, even with not keeping empty folders around.

Awesome site and lots of talent! I do love the logo as well - very clever but so simple too.

Hmm... I'm not sure there is a way around that to be honest. I originally thought of URL segments, but they only apply to things after the end of a URL. I think the only way to do that would be some sort of custom module to override the way PW handles URLs, but that would be far more trouble than it's worth I suspect given the number of much easier alternatives available.

I might be taking things a bit far with my latest idea, but I have plenty of scenarios where I on;y want a specific crop to be available to the first image in a list of images and not the rest, and then have a different crop available for the rest and not the first one (so first thumbnail bigger than the rest). I was thinking of trying to re-jig the code I did to allow crops to be tied to specific templates to something like this: big_thumbnail,300,200,news:first,article small_thumbnail,160,100,news:!first,article So in the code above, for the news template a colon separates the template name from a keyword - first - so the big thumbnail is only available as an option for the first image in the list. In the second config row for the small thumbnail, it is !first, with the exclamation mark meaning NOT (as it does in PHP). Both crops are available for all images in the article template as no image-specific setting is specified for that template. I did quickly look into this a few weeks ago and it looked a bit more complicated than the previous code change I did, but I don't think it's impossible. The only concern I can see here is that as soon as you re-order the images, the first image in a list might be further down the list, so I'm not sure what to do there. Maybe I should just assume that people would click Save once they've re-ordered the page and then they can re-select their crops as normal? I think that that would be a small price to pay for the additional functionality - especially since not a lot of people may find it useful, but I hope others might see the benefits and have some usage scenarios in mind too Anyway, it's not high up my list of priorities, but I thought I'd see who else is interested in this.

The simplest method has been mentioned - having an extra field for the template to choose whether or not it appears in the header or footer menu. Personally, my take on that would be to assume that all pages will appear in the header menu and have the extra field simply be a checkbox labelled "show in footer menu". That way you can easily output a header menu excluding pages with that checkbox selected, and output a footer menu for those pages with the checkbox selected. This is of course just variations on what others have said further up the page, but with field widths being adjustable now, you could even do something like make the page title field be 80% wide, have the checkbox 20% wide and then when editing pages the checkbox will appear neatly at the top-right of the edit screen and not take up a lot of space at all (which I'm guessing is the original poster's main issue with it?)

You might already know this, but if someone doesn't have edit permissions for that page then they won't see the Edit button (though you will for every page as you're a superuser). If you want to remove it completely though, edit site/templates/foot.inc and remove this: <?php // If the page is editable, then output a link that takes us straight to the page edit screen: if($page->editable()) { echo "<a class='nav' id='editpage' href='{$config->urls->admin}page/edit/?id={$page->id}'>Edit</a>"; } ?>

Oops - you're right, it does work in FF but I had forgotten to clear my cache! Thanks! Looking great once again

Hi Soma It doesn't work with the new variable width fields - they still sit on separate rows Take your time though - I'm only letting you know as I love this theme and use it on all PW projects

Oh. Oops.

My jaw is somewhere near the floor after that video ryan - that's amazing! Not only due to the fact that you can give names and descriptions (amongst other things) for fields on a per-template basis, but also seeing a very good usage scenario for the resized field widths! I hadn't thought of anything as useful as that yet but can definitely see quite a few templates where that sort of layout is going to work so I'm going to start playing with them right now to vastly improve my templates

I don't think the limitations are necessarily due to Linux then as I had a short-lived experience with a web host that had imposed a 4,000 file limit (files OR folders) in a given folder, so maybe the limits I'm thinking of are imposed by a setting in Apache. Something like that anyway. Or maybe the file system was ext 0.5

ReCaptcha used to be a bit easier to read for humans - now I usually have to get it to refresh a few times before I can read one as it's got a bit silly lately.

Yep - that can often be a worry. The good thing about PW is that whatever hooks your module hooks into will still be here for the foreseeable future, as will the current API. I'll leave it to ryan to confirm, but I don't see the current API calls ever changing to be honest (except in terms of new ones being added) as they're nicely abstracted from the functions themselves, so even if the core code for a $pages->find() call were to change (say something can be refined when PHP6 becomes the norm on webservers in a few years' time) then I still imagine the $pages->find() call in the API will be exactly the same even though the underlying code might get a tweak for performance purposes. Similarly, the hooks that modules use are logically named enough that I can't see them changing either - at least the ones I've used so far. It's this attention to detail - that I'll admit I've only just really thought of in this context - that makes PW considerably more future-proof than other CMS packages. None of this guarantees that modules won't break with new upgrades, but I would say that for most basic module needs that simply use the API to perform certain functions that they would be pretty future-proof.

Christoph - are you sure that the page in question's template has view access for guest users? I can't see why it wouldn't, as the default is for guests to view all new templates, but I'm wondering if this might somehow be the case.

I was just thinking the same thing, but I was thinking of sending data in and out. I think it would be too complicated for PW for various reasons, but would be awesome if it could somehow be configured to work with any page structure.

Wow! That sounds like it would be very useful in a lot of scenarios. I can already see this being useful for something as mundane as "if I have made a new Tweet then add the same message on Facebook". Neat - going to try this out at some point

That sounds great ryan - could you also add a cleanup script to remove empty folders on current sites? I guess this would be something separate since it wouldn't be required for new installs. I suppose the way to do that now I think about it is: Fetch every template via the API, work out which ones have an image or file field, iterate through every page using those templates and remove any folders for pages that have no content in those fields (via a simple $field->count() maybe?).

A super-simple one I employed on one of my forums was a Q&A. The question was really simple, such as "What colour is red" and required users to type the word "red". Simply having an extra field throws off a lot of spam bots especially in more common forms where they're used to a standard number of fields, and when they eventually broke through this first tricky type of question on the forum in question I was able to simply change the question to something equally simple. There was something very satisfying about changing the question just after they'd worked out the last one - I know it's probably all automated but I like to think I've frustrated a human spammer nonetheless

Thanks ryan - for some reason I completely forgot about FieldtypeMulti which will, as you say, eliminate most of the headache as well as be able to provide me with a more sensible single table in the database with many fields, which is perfect for the various scenarios I was thinking of (I actually mocked up an idea for the invoicing repeater before my previous post and noticed I was quickly racking up a lot of separate fields just for that, so this is a much better way to go). Sorry Soma if you had suggested that or that was what you meant - it wasn't until ryan said FieldType multi that it sank in

Just a quick one on custom modules - they were a bit off-putting to me at first, but if you're happy playing with the API then they're not too hard to create. As is often the case, the best thing to do is have a look at some other modules already created - the default install has a helloworld.module in the site/modules but a glance at some of the slightly more complex ones should also give you some pointers. The good thing is that it's pretty easy to hook into most things which leaves the rest of the module down to your programming knowledge (or in my case taking a lead from some of the other modules to see how some things are done ).

I did think serialized arrays at first and they would be cool too, but then you can't easily show multiple invoices for clients with total value outstanding etc - I'm thinking more complex, searchable, sortable needs which is why I thought of repeaters, as then you just iterate through each row and build your totals up to display at the bottom (on the front-end or a client-restricted admin page)

That's pretty much what I was saying - take a look at the example I linked to My thinking was that when they're in the database they're essentially the same thing, so rather than reinvent the wheel... You still want the fields values to be stored separately in the database - for example if you then built a template to display rows from an invoice it would need to calculate the totals for each row (quantity x unit price) and the overall subtotal, tax and total. Similarly you could then build a module to automatically email something like that to a client when the page is published. The way I'm thinking about it, a "row" is a repeatable element, which is where I thought it would be a natural extension of the current module (whether as part of this module or another additional module that requires the current module).