Craig

Cool I don't think so, no. I just checked a recent mailing and there is a "Mailchimp" button in the email footer under the unsubscribe links, but I think that is optional - either configurable as a setting or in the template. Essentially, whatever comes through to you from the "Send test" feature should be what goes out to subscribers.

I think you are nearly there! Instead of creating locations and products under the Admin parent page, create a new top-level hidden page called something like "Items" (or other name relevant to your sector), and then add the Locations and Products pages underneath that. As it's hidden, it won't show on the front-end; and then you can just grant your editor role permission to edit those pages via the template "Access" settings at either the "Items" template, or products or locations - whichever will suit you the best.

Mailchimp It's got a nice interface for doing just about everything you need to do. You can use or modify existing responsive templates, or create your own if you wish. You can easily add multiple types of content to messages. And all the other mundane stuff like managing subscribers and tracking who opened which messages. There are two non-profits I'm involved with who both use Mailchimp for regular member newsletters and it's brilliant. I'd say give it a go with some trial content and see how you and/or your client like it. The help guides are great too.

That's a good point... but if you want a link to a better song - in You Can Call Me Al, Paul Simon sings about a man walking down the street who "sees angels in the architecture"

If you look at the release names of Debian or Ubuntu linux distributions, I don't think they have a "target audience", per se. They just "are" names that are assigned.

Do you really want to have multiple image fields; or do you just want the ability to add multiple images to the same image field? The image fieldtype in ProcessWire supports multiple images - you just need to tell it so, when you go to Setup > Fields. A template can only have one occurrence of a field added to it. If you want more - you can either create multiple fields of the same type and settings but different names, or use repeaters. Have you read over the Images section of the documentation? It might help narrow down what you want to achieve.

Why would small projects need an alternative to ProcessWire and it's requirement for a database? Is there anything specific about the environment you're using (or propose to use) where a database would be an issue? ProcessWire works as great for small projects as it does for larger ones

I built some very basic Gravatar functionality into a bigger (site-specific) module recently - please feel to use it: Gravatar.module gist on Github

I would look at storing the cart and its contents as pages, with just a reference to the cart page(s) in the session or their user page. You could either use a parent-and-child relationship for these, or repeaters - best choice will depend on complexity of products I suppose This way, the "content" of the cart is always stored in the database using a consistent format, and you are just keeping a small reference to it where it's needed so you can easily get it. I would tie it all together using a module to handle just the cart itself - adding/removing items, setting/getting the reference to it with the session/user property or whatever.

Something like this <?php $newsItems = $pages->find("template=widgetNews"); foreach($newsItems as $newsItem) { ?> <article class="newsItem"> <h3><?php echo $newsItem->title; ?></h3> <h4><?php echo $newsItem->newsDate; ?></h4> <?php echo $newsItem->newsSummary; ?> </article> <?php } ?> Wrap each post's content in another tag which you can style separately. Here I used the article tag, but a div would work just as well.

Probably the simplest way to do this is to create a hook method or property on pages - rather than "injecting" variables into templates. The Helloworld.module file is a basic example of how to do this - example3 and example4 functions, but here is how it might look (completely untested - guide only!) Module init: $this->addHookProperty('Page::hello_world', $this, 'helloWorld'); Module function: function helloWorld($event) { $page = $event->object; if ($page->template->name !== 'my_template') return; $event->return = "Hello, world. The ID of this current page is " . $page->id; } Template: <h1><?php echo $page->title ?></h1> <p><?php echo $page->hello_world ?></p>

On Goldfinger... Trivia: it was actually Ian Fleming's dislike for the architect, Ernő Goldfinger, that lead to the James Bond villain being named after him [Wikipedia]

I do like this idea. Some of my favourite architects to throw into the mix... Bancroft Goldfinger Smithson Pasmore Luder Chamberlin Powell Bon

From the sounds of it, that doesn't sound like the best way to solve that problem. If you are having users log in, the best way to handle that is by using the built-in functionality because it takes care of secure credentials storage, authentication and session management. Could you describe in more detail what the user system doesn't do that you need it to do? Perhaps there is a different way we could help with? Perhaps you may still need separate pages for users, but not for authentication purposes.

Just a small comment (addition to Philipp's suggestion): In some of my PW sites, I use the existing "title" field to hold the user's full/display name.

Only pirates can wear masts. And even then, it'd be pretty awkward.

Sounds great The only problem I've noticed is the external link indicator icon. On Windows 7 - in Firefox 30 I get a lightning bolt, and in Chrome 37 it's just an empty square (see screenshot).

It sounds like the master site would benefit from having some form of RSS feed or web service making the content available. The other replica/satellite sites can read this feed when convenient, parse and download the information, and create local copies for their own purposes. ProcessWire will make this easy in several areas. You could use the MarkupRSS module to create the necessary feeds on the master site. PW's API is a breeze to use in order to create pages programmatically from various sources. You could schedule this to run on a regular basis to keep the sites up to date. This is just one way, and the way I might do it - but there are probably multiple correct ways to approach this problem with ProcessWire.

Yes this should be possible. Have a look at this thread - Is It Possible To Add A 'comment' Programmatically? The only thing you need to do is write some code to parse your XML and use the API functions to get pages, but certainly doable

You're welcome. The result on the website works well!

This should help: $events = $pages->find("template=sectionItem, parent=1025|1066|1073|1069|1013|1247|1101, sort=startTime, start=10, limit=3"); $events_array = array(); foreach ($events as $event) { $start = "".date(strtotime($event->startTime)).""; $title = $event->title; $events_array[] = array( 'title' => $title, 'date' => $start ); } $events_json = json_encode($events_array, true); echo $events_json; The reason is because before, you are simply json_encoding one PHP array at a time into a native javascript object. This way, you are creating the eventual array of objects - first in PHP, and then asking json_encode to work on the whole collection of items.

That looks awesome Ryan!

OK The error could be somewhere in the .htaccess file. Have you got the new and original (pre-upgrade) versions of this file? If so, you could try swapping them over to see if one works.

To help track down the error, there may be some entries in this log file: site/assets/logs/errors.txt

I think this is a very good discussion to have, and it's interesting to see how other people handle this situation. As a developer, I'm often wearing one of two hats - one as a lead developer in the company where I work; and the other as someone who builds and maintains websites (using mainly ProcessWire) outside of work for organisations and people with a personal connection (or even just sites for myself). At my company, most of our time is spent on software as a service apps built using CodeIgniter. We work locally on databases that match the structure of live ones. When we make schema changes in development, our tools (Adminer, HeidiSQL, phpMyAdmin etc) provide us with the SQL query that was executed. We put these in .sql "patch" files in the project repository (patch1.sql, patch2.sql...). We also have a custom script in the application which runs these patch files on-demand at the staging and production servers. The application database has a patch history table to keep track of what it has, and the script will then run the patch files it needs for the database schema to be "up to date". As a team of three developers, this works well for us and the way in which we manage changes to those projects. The key to this process working for us is having the queries available and recording them appropriately when we make changes. They are plain text and tracked in source control. I think what I described above is similar in some respects, in practise, to the "command objects" approach talked about in this thread. Wearing my other hat - due to limited free time, some website changes take a while to implement from start to finish. Sometimes this can also be the case where I work, but not always. During this time the content is likely to be changed by the client a lot. In this instance, it's not really feasible to impose a no-change restriction on the site whilst I spend days and weeks implementing a change or new feature. Taking those into consideration, I think what would work for me or the company, is some form of file-based change or altering commands or instructions which can be ran on a destination site, and have them made on there. Whether the ProcessWire UI logs or shows these in the UI or actually generates files (as a configurable item) doesn't make that much difference to me and my workflow.