Pete

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

There were some other inconsistencies in there as nowhere was I echoing the name of the artist and I spotted one more mistake too, but fixed now thanks The beauty of the system is that this is a fictitious scenario, but if you spend a little time with ProcessWire you can code front-end templates without having actually built the structure in the backend - it just becomes really intuitive.

I'm not sure, but it might be worth checking if a new page created in the admin actually adds the user ID to the modified_users_id when creating a page that way as theoretically the page hasn't yet been modified. It's a long shot and I'm fairly sure I'm wrong, but it would be worth checking that first if only to rule it out.

Hi there and welcome to ProcessWire. I wouldn't worry about scalability as it's been tested with at least hundreds of thousands of pages and your first limitation will be with your server to serve content to what I would assume be millions of visitors each month. There's not a great worry about backend performance as features like pagination are actually built into the tree (if you open a parent element with 100 children for example, it will display the first X amount with AJAX pagination for the next page and so on). In terms of database performance, everything is nicely indexed as well. The trick with ProcessWire is that whilst everything is a page on the surface, a page can be anything you want it to be and it certainly adds to the flexibility over some other CMS'. A lot of the questions I had when I moved from MODx to ProcessWire revolved around "can I do X in ProcessWire" as every feature I had built into a previous MODx site seemed to take a lot of effort with some really long snippets and some complicated PHP, but ProcessWire not only let me replicate every feature but allowed me to do it in about a third of the code, if not less. The beauty is that whilst there is some PHP to learn, the API is jQuery-inspired and you shouldn't have to write a single line of SQL as the sensible API calls allow you to do things like this, which whilst requiring some PHP knowledge, leaves you with code that is easy to understand if you have to tweak it months after writing it: <?php /* Let's assume we have a music site - there's a section for artists, under artists we have albums and under albums we have tracks. All are pages (artists would be title, images, body - albums similar and tracks could contain title, length and writer(s) if you like just to give you a rough idea of flexibility - I'll keep the code simple though. */ // Iterate through the artist pages, echo the artist title and body field foreach ($pages->get('/artists/')->children as $artist) { echo "<h2>$artist->title</h2>"; echo $artist->body; // Now list all their album titles and body field foreach ($artist->children as $album) { echo "<h3>$album->title</h3>"; echo $album->body; // Finally list each track on the album echo "<ol>"; foreach ($album->children as $track) { echo "<li>$track->title</li>"; } echo "</ol>"; } } My MODx/PW relationship started out as "let's look at another CMS" and I was quickly converted to be honest. It's easy to understand once you get past the relatively small learning curve and we have folks here who consider themselves beginners but who are coming up with some amazing site profiles and modules. One module which I think might be of interest to you in terms of scalability on the front-end is ProCache. If you have a lot of static pages on the site then that would be invaluable as it caches and serves pages as pure HTML with no PHP or mySQL queries (for member-driven sites it could easily be used to display pages to non-logged-in users rather than touching PHP or mySQL, so anonymous guests get a lightning fast performance and don't add much load to your server). Past that, there are a few other caching options available to you either in the backend or things like MarkupCache (if you have a drop-down list on the site for example that can be updated by adding a page in the admin - a new Album maybe in my above example - then you can use MarkupCache to build that list once, cache it for X hours and only rebuild it after that time. There are other caching options too though so it can be cleared on page save etc). Sorry, my train of thought is meandering a bit this morning, but the short answer is "yes, you should spend some time making friends with ProcessWire" http://processwire.com/talk/topic/2675-processwire-pro-cache-now-available/

The issue is that these two statements are not compatible: From what I can tell, almost every page on your current site has information stored in the database so there is no simple "file" to edit to change content - that's the main roadblock for you in terms of finding a simple solution. I honestly think you'll have to move the content across to any system you look at, be it ProcessWire, Perch or any others (Perch works with static files, your site appears to be mostly database-driven and would need to remain database-driven for things like the search and other functionality to work). ProcessWire is based around pages and all sorts of content is treated as pages. It uses its own database so you can't just say "use this unknown database here for old pages and the PW database for new pages". Even if the database structure were the same (and I guarantee they won't be) it would still be very difficult to achieve and not worth your time. To get any CMS playing well with your current database you would have to write a lot of custom code, which is far harder than simply (and I realise it's not that simple) importing the current site into ProcessWire. I do believe though that moving the existing content into ProcessWire would be easier than any other CMS I've used, and I've used quite a few over the years. The beauty is the content is already in a database so we don't have to parse any static pages to do the job - it means the relevant field contents from the existing DB can be more easily ported to related fields in ProcessWire. For example, you can bootstrap the API in an external PHP file, query and iterate through your current database and create pages like this: http://processwire.com/talk/topic/352-creating-pages-via-api/ There's no need to overhaul the site - the existing page templates are fine if you're happy with them - the content just needs moving across and all page queries replacing with ProcessWire selectors, which is easier than it sounds at first (and results in far less code ).

Welcome hafa This post on the previous page has the link to download: http://processwire.com/talk/topic/1421-twig/?p=12807 Since porl says in his last post he considers it final unless anyone sport any bugs and nobody has replied since, I'd say it should be pretty stable

Yep. Just add PHP inside Javascript on your page like so: <script> var varname = '<?php echo $phpvalue; ?>'; </script> If you put this in a template file, since you're declaring a global variable there it should be available to external .js files too. You might want to wrap the jQuery documentready bit around the JS though. Remember - PHP is server-side, so that line of PHP will be parsed into a real value before it hits the browser, therefore if your $phpvalue was hello (for the sake of arcument) then your source code when viewed in a browser would look exactly like this: <script> var varname = 'hello'; </script>