Andrew Means

My 'expertise' is kind of outta left-field, as I'm completely self-taught. So there's probably a ton of things I'm accustomed to doing that aren't really good practices, but hopefully I'll bring a different perspective to the table. It does seem like the overarching goals/methodology is similar - that is, to make tools that maximize flexibility and then build more specific things out of those tools, rather than build a different tool for every job. I used to explain Versa to people like a Video Arcade vs. an NES with a bunch of cartridges. The Arcade has a bunch of games (processes) and each have their own self-contained box. Each box is doing different variations of the same thing (adding, editing, displaying, sorting, deleting, etc.). The NES has one box & one screen, with different cartridges that specify the game. Rather than duplicating the processes for each different thing you have, you build core functions that handle all the processes, and that vastly streamlines the work and makes each client's backend completely customizable. If you're interested Ryan I'd love to give you a rundown of Versa over skype or something - lots of similarities between the two systems, both structurally and from a UI perspective.

Awesome! I know it probably sounds like I'm being all wary and stuff but I'm excited about working with this system/framework (and likely contributing modules to it). I like the UI a lot and its unobtrusiveness with regards to the front-end markup. Great work!

Yes, I get it, that makes sense. I think I like it. In my CMS I was dealing with similar issues; I had Nodes, which represented the main structure of the site, and then nodes were assigned node-types. The node-types were called 'Things' which were essentially Models - these were initially represented by an a collections of fields in an associative array, but eventually were stored in the database. Each Thing was basically an abstraction of whatever thing we were dealing with, whether it was a site page, a testimonial, a wine, or a staff member or what-have-you. And the type of thing determined the kind of behavior the node had. Some had many children of the same type, for example a node with the type of 'wines' would be able to create new wines, list the wines it had created, sort wines, etc. And some nodes had a one-to-one relationship; e.g. a node that had been given the node-type of 'site content' was able to edit the content for that page, and create new sub-nodes/pages. Anyway, I digress. One of the things I can't decide if I like about Processwire is that, since everything is a Page, your client can put *any* type of page as a child of any other page. It's simple, and probably most of the time it's a benefit, and it more simply solves some of the issues I was having regarding disparate content types along the tree structure. I really like the simplicity that that gives, especially dealing with URLs - in my CMS I had big challenges trying to figure out how to write fully semantic URLs. Overall I like it. It's weird seeing the different ways this system is dealing with the same problems I was having; I'm sure I'll have plenty more questions but it's really good to grasp the deep concepts first.

I think I was getting confused by the nomenclature - there are often things on your average website that aren't strictly 'pages' and it seems odd to conflate everything into the term 'page'. Also the idea of there really only being one Model (page), but a bunch of different Views (templates) is an interesting way to attack the problem of flexible website building... It actually does solve a few problems I was dealing with in my home grown CMS but also raises some interesting questions about traditional information architecture. Interesting...

Maybe I didn't explain this well enough - that's precisely the tree I was envisioning, but I'm at a loss as to how to create the requisite fields for the wines, events, and reviews, and especially at how to make the reviews relationally bound to their respective wines. When I go to on 'Setup > Fields' I see a list of fields, but these fields only have to do with a page. Is it that there is only one type of 'thing' that processwire really deals with, and that's pages? And then there are just different formulations of those pages that have different groups of a master list of fields? So if I want to create the ability for my client to add a new wine, I need to add all the 'vintage' and 'varietal' etc. fields to the master 'fields' list, and then create a new template that selects those fields?

I may be overcomplicating things in my head, but I'm trying to understand a few things about information architecture in PW. Perhaps the best way to get my question answered is by a hypothetical site. Say I'm building a website for a winery. It has a number of different types of information to display: Standard page data (headline, subhead, images, body copy, etc.) A list of wines that have their own attributes (varietal, vintage, price, description, image) Each wine has reviews associated with them, which have their own attributes (publication, author, score, link). Testimonials (testimonial text, author) that need to be randomly displayed on certain pages. A pagable list of events at the winery (sortable by date, etc.) How would I go about setting this information architecture up in ProcessWire?

Hey all - I'm just getting started with Processwire and I'm pretty excited about what I've seen so far. However I have a lot of small questions and I'd love to be able to bug somebody about them without listing them all here as separate threads. My skype handle is randunivac & my gchat handle is andrewembassy if anyone wants to volunteer to let me pick their brain. A little about me - I run two small design companies, Réunion and Transom Labs; I somehow manage to straddle the line between designer and developer, and really enjoy getting deep into PHP/MySQL as much as HTML/CSS/jQuery and Illustrator and Photoshop. I'm self-taught and over the past 5 years have developed a CMS called Versa, oddly similar to Processwire in many respects. It shared many of the same features (hierarchical menu structure, it handled all the MYSQL, etc.) It works well for my smaller clients but I don't have the time to make it into a truly enterprise-level system for some of my larger clients, nor do I have the time to support it and make open source. So I'm in search of a solution with a good community of developers and a solid foundation to build on. Like I said, I really like what I've seen so far with Processwire and if I decide to use it I expect I'll be submitting lots of new feature requests and modules. I would love to pick somebody's brain about it over phone/skype/gchat if anybody has a minute! Andrew