Pete

No probs, but not sure it was me that mentioned oembed ryan - think I said I'd build this module and then never did (there's a theme there ).

I would still choose Minify since it already handles CSS as well and doesn't require the .htaccess: http://code.google.com/p/minify/ I've got it working on one site already, but I don't know that it's really worth a module to be honest since its already easy to set up (there's a helper script included that pretty much builds the URL for you). I just put mine in somewhere like /site/lib/min/ and put the relevant URL in head.inc for the JS and CSS. A module could save a little time, but in the case of Minify it would be about ten seconds EDIT: I did just think of a way a module could save a lot more time actually so I might build this module soon. EDIT 2: my first thought was to make it inject the relevant code before the head tag but that's nt always ideal plus you don't always want all scripts/stylesheets in every template. I think I might just make it give the relevant code to copy and paste into the template instead.

I was a long-time MODx user before PW and it does take time to un-learn your previous system. Moving forward though PW is pretty easy to pick up with the right examples - the people using it have a wide range of programming knowledge and ability. It's always interesting to see what people come up with and gratifying to see them get going with it after asking a few questions here, so if you have any other queries or suggestions please keep them coming.

Oddly in Windows it's Alt+F4 to quit an application, so Alt+Q probably starts your car by that logic Not saying Macs make any more sense mind, requiring a key with a fruit on when they ran out of letters and numbers that by all rights should produce an apple when pressed.

Yup, what they said

Just after your foreach I would do $thumb = $feature->images->first()->size(325,325); and then you can output $thumb->url and description as normal.

No probs - no such thing as a bad question. You'll want $feature->images->first()->url and if you want the description too then same as this but description instea of url

I'm with you on that Soma. Even on my largest site with 400 pages there are only a few images (maybe 5-10) that actually needed to be re-used elsewhere. The more I think about file managers the more my head hurts nowadays, but it did seem odd at first coming from MODx's file manager (something hooked up to TinyMCE) but after you get used to it it's far easier this way for most purposes I've found.

I don't know whether you could work around it by checking if an input field or textures is selected before deciding on the action? If a field is selected it would make sense to leave it as paste, else view page in a new window maybe.

Soma - CTRL+V is paste on a windows PC so not sure whether there are any issues there? Just a thought.

The other really big issue that being able to use images from another page in an image field would introduce is if the page that image was originally from gets deleted, as presumably you'd want to link to the original rather than copy it (although copying it to the current page would certainly get rid of that problem and I can't imagine images getting reused that much really).

The thing to remember about PW though is that files uploaded to a page are stored in a folder with that page ID rather than a separate folder structure, making handling them in the current page very simple. That obviously then adds a few problems to an overall file manager, but I suspect that you would usually know whih page certain images are attached to so it's not that big of a problem. It is quite a large undertaking though as you'd probably want a decent search feature to find images by page title or by image description as well as other features. It's also worth noting that you can already insert images from other pages using TinyMCE in PW, so that functionality is already there. Technically you could create a gallery template with just a title and images field and create a structure for storing images in a structured location that way, but as you're already aware you then have the issue of not being able to link to them in an images field. Lots of things to think about and it's a complicated topic.

Never realised about duplicate removal - I can go and trim some code back on a few sites. Thanks Ryan

Very nice site! Well done!

Yup - technically menus other than the main Nav rarely change. It's not a bad thing to hardcode static menus but I can obviously see why there are occasions you wouldn't want to.

I'll look at it when I'm back at home (after the weekend). Technically on my hols but have sloooow Internet on my phone that I don't mind using for checking the forums

The only way I could see to do this is create a template that has a Title and Page field - then create a hidden YourMenuName field under a hidden Tools page (or whatever) and start building your menu using this template. It's simply a case then of building your structure using this template, entering the titles and linking them to pages in the site. Rinse as repeat for as many menus as you like. That in fact is pretty much the only way you could build entirely different multi-level menus to your main site structure, and it's also really simple. I might have to like my own post

I'm sure there is a page break tag on HTML I've used before once for printing purposes. If its still a valid HTML element it might be a button that can be enabled in TinyMCE (can't check with slow connection on my phone) and that would make life very easy.

I don't think that's going too far with template specific field perms ryan - could be useful on larger sites where fields are more likely to get re-used many times.

Definitely worth checking out Minify if you have a lot of CSS and JS files (or even if you only have a few since it makes for less HTTP requests). It used to be a bit of a hassle to use in the early days, but it's really simple now and shrunk my JS files to less than half their original size, even squeezing already-minimised versions of the jQuery core down further (presumably these are compresse some other way).

Love it - nice, clean design

In terms of a Google map page, you generally have one of these on a website so a different template would be the solution for that one. If you were building a real estate website and needed one map per property then you would have a property template and have the map code in that template file (presumably with the pin location being determined from an address the user has entered into an address field). Both of these scenarios would preent the user messing up the map code whilst still not requiring lots of different templates. That said they're only specific examples. I think that one solution here that might be something that could be built on top of Soma's example is to have a hidden tab of fields you want to keep away from the user. You may not be aware but you can create new tabs that are visible on the edit screen itself, so it seems like it should be reasonably easy to code something to hide a whole tab (would require some PHP for checking perms and probably a little JS to hide the tab). That said, Soma's solution would still leave the fields in place in the page flow if you prefer, but I was thinking a hidden tab for your fields would be more flexible as you can easily add more fields to it without tweaking any code.

I think the thing we're missing in this discussion is a solid scenario. The MODx way you mention is one I've used myself - sticking in a field where I can drop a bit of code in (in my case a field where I can add page-specific JavaScript but it was only on a tiny site and that could have been handled in an external JS file by tagging the body tag with the page name as an ID since the code would never change), but I only ever did that on one of my personal sites and I've not needed to do that in PW. If you could give an example of where like you say you might have a hundred pages but want to add different code to each then we can possibly offer you a solution you may not have thought of

LinkMonitor sounds great to me. Love the added features

Nice example slkwrm - I hadn't thought about permissions much before beyond the basics but there are a few projects in my head where I will need to build a front-end admin system ad this will prove invaluable along with various roles so thanks for that!