Pete

Too... many... toilet references... ryan But yes, I instantly thought of plumbing too and agree with someone's comment on the MODx forums about the logo being reminiscent of the HTML5 and Magento logos. I think the only logical reason for another name is the fact that the new service will host other products such as WP, but it would have been nice to somehow keep it similar whilst descriptive somehow (xhost.com is for sale by some cyber-squatting domain holding company for example). That aside, the need to raise money through one service or another to keep a team working is just something that happens when many open source projects get to a certain stage from what I can tell. At some point during the lifecycle of a few of the projects I've kept an eye on, someone ends up working on support full-time or on coding full-time, and there needs to be a source of income at that stage. Usually the full-time coding side of things comes when the project attempts to add something massive as part of the core or rewrite all of the code every few years, but we're blessed with ryan developing optional modules to add functionality and having created a wonderfully abstracted API which allows for code changes behind the scenes and a set of API commands that will change very little if ever in most over the years and not break backwards compatibility *finally takes a breath*. Commercial support is a subject that has cropped up elsewhere on the forums in the past so that is about the most corporate thing that I can think of that might be on the horizon for ProcessWire as several devs have enquired about it, but that's a topic for the future, is something that doesn't affect 99% of users and doesn't affect the usual support on the forums anyway as it's all about paying for SLA's by web dev companies and... businessy stuff... (sorry, it's late and my brain is clouding over with a headache ). I've not been keeping up with MODx in recent years, but whilst they have always had a small, core team of devs doing most of the work I think a lot of ryan's impression of them being a big company may come from an active community (we're getting there as well, definitely!) and a smart looking website (nothing wrong with ours, just picking a description for theirs). Their website when I first discovered MODx definitely said "open source" to me: http://web.archive.org/web/20080103101906/http://www.modxcms.com/ whereas the current one is simply more businesslike and makes them look bigger despite it being more or less the same core team as 4 years ago. I wasn't really going anywhere with that last paragraph other than to say that it's difficult to gauge the size of the team or the capital behind a project from looks alone as the two are worlds apart - and there was a friendlier design in between that one and the current one too that reminds me a bit more of the current ProcessWire site and I think they should have kept for longer: http://web.archive.org/web/20110208164501/http://modxcms.com/ Whatever changes are made to any project, if they're big enough then some people won't like it. A lot of people just don't like change, but much of it can be alleviated by releasing a comprehensive FAQ when such changes are made as it prevents much of the speculation that so quickly spirals out of control. Anyway... my train of thought has pulled into the station and I think that's my lot for the night

I see you've asked that last question over here franci: http://processwire.com/talk/topic/3311-is-pw-a-framework/ - just a heads up for anyone responding to answer there instead since it's a different topic

Technically CodeIgniter and CakePHP are also "pure PHP" and a framework simply gives you a way to get a headstart on development using pre-defined classes etc. I think what you're really asking is if you can use it as a framework and just access its classes directly as with those framework and the answer is definitely yes, but there is no single correct way to work with it which is the beauty of it In ProcessWire, to use it as a framework you would bootstrap it and use the API to get stuff done. Here are some helpful links on that side of things: http://processwire.com/api/include/ - The first few lines show how simple it is to include and get started, then this one shows you the vast majority (maybe all?) of the API functions on one page: http://processwire.com/api/cheatsheet/

With curly braces?

Amsterdam was a blur for me - I was there on my stag do...

Hi Ronnie - as horst says in his first reply: So it doesn't even attempt to check orientation at present. It's a fairly uncommon issue, but at the same time I don't think it's hard to read EXIF data in PHP (sure I've done it before) so it should be something that can be resolved as it would certainly help on photo galleries where this could crop up on newer cameras. Not that I know how - just explaining out loud EDIT: Here's the solution - http://stackoverflow.com/questions/7489742/php-read-exif-data-and-adjust-orientation - the original poster shows how to read EXIF rotation, then actual image rotation is pretty trivial from there. EDIT2: I just re-read horst's replies and the updated code sounds like it's on its way to ryan

I actually wrote a serious one line reply along the lines of "WTF?". Then I deleted it once my brain engaged

I'll weigh in and say it's worth looking at some of the easier tutorials too. This topic mentions a couple: http://processwire.com/talk/topic/2565-rocking-the-pw-wiki-small-project-walkthrough/ It also mentions the Wiki which is worth a look too.

I can confirm that it works in your example, just not when I include it in head.inc - I get this error: It's peculiar I know since the filename should make no difference. I then renamed my default head.inc to test.inc and updated the code in the homepage template and it throws a 404, renamed it back to head.inc and changed the include in home.php and it logs the error message above again.

Just a couple of notes - firstly, for anyone reading into throwing 404s in ProcessWire the preferred (as in used more in code samples here) way of doing this now seems to be this: throw new Wire404Exception(); Also, I tried using an include file at the top of my template called global.inc that does some global bits and pieces and I noticed that it seems impossible to throw Wire404Exception in an included file - it amusingly throws an exception

I was about to snap that up to secure it but Adam beat me to it by the looks of it looking at the whois records

The other thing to note since ryan wrote that post Peter is that you can change the label for a field on a per-template basis now. So for example if you have a body field but want to call it something else, you can add it to a new template, click on the field name and change the label for that specific template. That way if it makes more sense to call it something else but makes it easier to refer to it as "body" in searches you can still get the benefits of re-using the field but giving an appropriate name to any editors.

Also, a quick note as to why it's recommended against doing this usually is that all it requires is for someone to delete an image or rename it or whatever and your link is then broken. That is why you will usually see people recommending against it unless you're re-using lots of images all the time - as in your case. It's not that it's a bad thing to do and in your case if you're reusing the majority of your images it makes sense to do it this way, but there are other benefits to having the images in a field attached to the page, such as per-template image cropping as well as simply not having to let editors insert images into the WYSIWIG at all (i.e. layout is completely controlled in the template file then instead without an editor user having to resize or insert an image - simply upload and away you go). Of course whatever suits your scenario is obviously right for you - just thought I'd explain the benefits of the other way for future sites you might want to use ProcessWire for. EDIT: In fact I'm pretty sure this was one of my first questions when moving from MODx too EDIT2: Forgot to say welcome to ProcessWire!

This topic has come up a few times and this method of image management is required for some websites (often article sites where you might have one image for a subject and re-use it). arjen posts a good solution which may or may not be what you're after, as it relies on knowing where the image was last used if you're re-using it. It might suit your needs, but I'll offer up an alternative. A simple way to achieve this as per your requirements of 3 directories of images is to create a template called "gallery" and simply give it an "images" field. Then, create 3 pages (mark them as hidden) to mimic your 3 EE directories and add your images. In the WYSIWIG editor for any page you can select an image from another page, so this in effect acts like an image gallery for you in the way you're used to

Good point! Okay, so I know a lot more but didn't want to boast. I think the biggest hurdle I found when moving from MODx was un-learning the ways of doing things in that system and learning the way of doing things in ProcessWire (some of which seem odd to begin with, but genius when you get going with them). Back to your checkboxes, the way to do it is like ryan said and hopefully you can re-word the label to be the opposite as long as it still makes sense with the new label?

I think it's the other way around - you might not need OPcache at all if you use ProCache Multiple caching methods can't hurt though as it's highly unlikely there will be any conflict (like Martijn says ProCache is all about serving static versions of site pages with no PHP or database). OPcache could be useful if it offers any more compression on plain HTML and certainly on pages you might choose to keep out of ProCache like pages with dynamic elements etc.

Wow, that must be one of my first ever posts on the forums you've found there I know a little bit more about ProcessWire now Are you talking about editing a page with those checkboxes on, checking one of the boxes then saving the page and editing it later? If so the relevant box should be checked when you go back and edit the page, but I don't think that's what you mean.

Welcome! Sounds like you're working on some really interesting stuff there andy - it'll be interesting to see the groupware project!

I feel bad getting likes for ryan's work... there was me thinking I was late noticing this as I've not been around in a while

I think there are quite a few people here who had little PHP knowledge to start with that are getting on really well with ProcessWire and producing some excellent sites, but I know what he means as PHP can put people off before they've even tried learning a bit of it. I think the point there is that ProcessWire is for people who want to try and expand their knowledge a little (or a lot) rather than those trying to find a magic system to do it all for them - which usually means their website will take 5 times longer to build than with PW. For example, I manage an Intranet system which I first built about four years ago. The code is old and cobbled together. I'm now building a ticket system/helpdesk module that integrates with is and has all the features like departments, emails converted to tickets etc and it's 50% complete in less than 2 days (a few hours here and there spread over several evenings). I can't think of any other CMS or framework that would let you shave this much time off a project!

Raymond - it's been several years since I actually laughed til I cried. Thank you, I was also on the verge of wetting myself.

I've not been keeping up to date with the forums recently due to work, but couldn't see a topic about patting ryan on the back for the awesome work he's done on the new modules section layout: http://modules.processwire.com/ Amazing job ryan - it looks fantastic!

Well if it's a busy site they'll be querying Piwik potentially thousands of times an hour (not sure of your visitor numbers) whether they're a search engine spider or not. I think your solution here is to use MarkupCache and just update it once every hour. That way you're not hammering Piwik or slowing things down for your users. Even Google Analytics doesn't give you up-to-the-minute page counts by default (I think they update every 2-4 hours unless you're viewing some live stats). Of course if it's a site with very few visitors then I'm not sure why it would slow it down so much.

diogo's code means we could have it delete the site on triple-clicks though and destroy the world on quadruple clicks with just a few adjustments

As an ex-MODxer myself who's been using ProcessWire for almost 2 years I can confidently say ProcessWire will handle everything you need. Much of what you're after are features I've built myself on one site or another with ProcessWire so you're definitely in the right place to build the site you want in a fraction of the time compared to doing it from scratch - once you get going I'm sure you'll be amazed at how fast you can get things built without having to touch a line of SQL or create any custom tables in your database since ProcessWire does that side of things for you