Pete

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>

Yeah, you're right - it would be a little complex as an inputfield. This may help for the photographers then: http://www.dropresize.com/ Basically they can create a folder on their desktop, tell this program to monitor it and set some settings and then they simply copy images into it and they automatically get resized. Would need some documentation though (the guy's site vanished with some dodgy host and hasn't been rebuilt yet, but it's not too complex to figure out from the app alone) but it would certainly make things much easier for the photographers

I think that that class is in most PHP versions from the last few years so I'll give my views on zip in PHP here since it's relevant to the discussion. There will always be some hosts that don't compile PHP with all of the modules but you have to draw the line somewhere to stop having to include 3rd party libraries in your modules and I think that PHP's zip functionality is pretty standard so I'd say go with that. My only reservation is that it doesn't have recursion built in (I mean you would think there would be an option to zip a directory and all children as standard but noooo ) and you'll be gathering a lot of info from people's comments and Stafkoverflow rather than the actual docs but you'll get there if you persevere with it.

Replace id and id2 with actual numbers in Soma's example. You can get the page numbers in the admin by clicking on a page name and clicking the edit button - their ID will be clear in the URL.

Love it. And yes, with some thought you could have promoters adding photos on the actual night of an event as long as they're not uploading the 20mb versions. Something I've used in the past is a Java upload/download script, so if the promoters had a laptop (won't work on a smartphone) images would get appropriately resized on their machine on the fly before upload (search javapowupload) and really cut down on upload times (thus is how Facebook used to do it). It would require a custom upload form but can be done relatively easily if you wanted to go down that route.

Fields are tied to templates so there's no way to tie then to a specific page without a template. Furthermore if you're talking about actually creating new fields on the fly whilst editing a page this would actually be quite difficult to achieve since most fieldtypes have many settings across several tabs.

That's great ryan as in a module just the other day I was using Sanitizer which was getting me so far, but this should give some additional useful options

Certainly useful for larger sites and I can think of at least one that would make use of this.

I would actually separate out each Vendor and each invidivual Product to be under their own tree like: /vendors/vendorname/ /products/product-1/ You then just use a Page fieldtype to link products to relevant vendors: http://processwire.com/videos/page-fieldtype/ and then use code on the product name something like this to pull the vendor into the product page: <?php $productvendors = $pages->find("template=vendors, id=$page->vendors"); // Assuming you could have more than one vendor per product $productvendor = $pages->find("template=vendors, id=" . $page->vendors->first()); // Or just one vendor You can also do it the other way to view a vendor page and list all products they sell: <?php $vendorproducts = $pages->find("template=products, vendor=$page"); // Assumes your Page field is called vendor

I do have a habit on a couple of sites of having the current page added to the breadcrumb but without a link. It just feels more complete to me. If it sounds odd, go back to the fairy tale and assume that the current page without a link is the spot you're standing on without dropping any breadcrumbs. "You are here, in case you didn't know and don't see the title in an obvious location on the page" can actually be relevant if you arrive at a page from search results for example, but I think it's more about personal tastes than anything else.

Since each field is its own table, I would sync any beginning with "field_" as well as fieldgroups, fieldgroups_fields, fields and templates as a minimum (which is actually the vast majority of them). If you're developing a site where permissions will change a lot then you'll probably want page_access too.

I was assuming each author has their own account and therefore they would receive those emails instead of/as well as the system admin - I might not be understanding your setup well enough though. In fact, it's not as simple as I thought as individual authors couldn't moderate just their own comments with the module (assuming you wanted to?) unless you rewrite a chunk of the module and let them have access to the comments manager. Well that just got more complicated

I'd agree with the above. You would almost want to give your template developers naming conventions for fields and a list of fields currently available, then whoever is managing the backend receives the new templates with a list of any new fields they need to create. Once the fields are there you can drop the templates in and they'll just work It is possible to work this way even without a local database when people are proficient with the API, but the problem is when you get a larger team and how someone has set up a field locally isn't necessarily the same way the person managing the backend does it. I suppose if you had a site that big some sort of field settings exporter would be nice.

I think that a config option in the core module might make sense here, and I don't usually suggest that but in this case I see it just being a checkbox labelled "email post author when new comments are made" which seems a but much having a whole module for it. In this case it would work for one blog with multiple authors or multiple blogs as well. To be honest, you'd then want another one to toggle whether the admin email address gets an email with every comment as well as this might then be unnecessary on some sites. The more I think about it the more options I want to add to the config but then we're getting away from a simple config option

I think you might get access to the password value if you hook before the page is saved, but I don't have time to give an example just now (Soma or someone else with fast typing fingers will doubtless be here soon with an example).

In fact, the functionality for this is simple - allow users to post links to each gist they want to list here, on submit split the gust ID off the end of the URL, check it's accessible (not private) and the sky's the limit Obviously some thought needs to go into categorisation and other relevant fields, but aside from that it's relatively straightforward.

Ah, now that is perfect because of the API: http://developer.github.com/v3/gists/ Just needs some thought about the code behind it and having users here list their own gists (wouldn't want to get all for a user unless they're relevant).

Surely this is the modules directory? Or am I getting confused?

The general rule of thumb is that anything that the majority of people wouldn't use exists as an add-on module rather than in the core. That's not to say something like this isn't useful, I know it would be, but it's not often you would need full-blown emailing capabilities like that. It's usually relatively easy to implement external packages as modules though to make config nice and easy through the ProcessWire admin and make it easily callable without needing to know paths etc so maybe that is the way forward for it.

You should be able to iterate through fields without knowing their names - the Cheatsheet should help you there. Something along the lines of get the page template, iterate through template->fields and then you have access to do something like $page->($field->name)->removeAll(); Just typing that quickly on my phone but hopefully you get the idea.