Leaderboard

Hi everyone, Just wanted to share this project I finished last month for a client. The design is not mine. I've implemented and converted the Illustrator mock-up into Processwire, and it went very well. There are some things regarding the design I would have change, but I could not go against the designer. Here's the link: http://www.setaiasia.com Special thanks to diogo, soma, yellowled for the support and, of course, Ryan for creating this wonderful tool.

You actually can use the 'sort' property, but you'll want to perform the sort after you've assigned it to all your items, because PW will write them out in the order that they appear. For instance, here is how we might reverse the order: $cnt = count($page->images); foreach($page->images as $image) { $image->sort = $cnt; $cnt--; } // now tell it to sort by the field 'sort' $page->images->sort('sort'); // you may not need to do this, but putting it here just in case $page->trackChange('images'); $page->save(); Avoid calling $page->images->remove() just because that will queue an actual file to be removed when the page is saved. Another way you might accomplish reversing the order: $myImages = new Pageimages($page); foreach($page->images as $image) { $myImages->prepend($image); } $page->images = $myImages; $page->save();

You are close on this. You can't actually give a field a different name. A field name is the same no matter what template you put it on. It is a constant. Though you can change the label or description according to the context of a template. Fields are not fieldtypes, they are variables on a page. There are fieldtypes in ProcessWire, and you can have as many of the same fieldtype on a template/page as you want. You do have to create the fields (of your chosen types), and assign them to your template. But just like you can't have two variables in PHP named $foo in the same namespace, you can't have two fields on the same page named 'foo'. If you need another field just like 'foo', then clone it and name it 'bar' or 'foo2' or whatever you want. You can create as many copies as you need. In the admin, Setup > Fields serves as your master directory of all fields in your site. To take the example further, some types in PHP can contain multiple values, i.e. arrays. The same goes for ProcessWire, as some fieldtypes are multi-value fieldtypes. Examples include page references, files, images, comments. There's also the 'repeater' fieldtype, which appears to throw all rules out the window, but that's in appearance only as it is technically mapping everything within the rules behind the scenes. Underneath it all, every field maps to a database table, ensuring that everything remains quickly selectable, searchable and consistent throughout the API.

I totally agree with this. I even think we should take this as concept for PW. I really like the way things are happening here. Most modules are discussed in the forum, and each module gets lots of input from the community before it's finished. I know that it isn't easy to keep it like this, as the number of users and developers grow, but would be great if it would be possible to keep a truly useful official modules repository (not too big, and without repeated functionality). This could be done via the forum, and via a small number of administrators who would filter, and propose the merging of modules with the same functionality.

Thanks for testing Apeisa and Sinnut. Right now the intended audience is us, as you might guess from the included blog entries. But once everything is worked out with it, the intended audience is folks that want to write blog entries and don't know how to do any development. That's the audience that we have no connection with at all right now, but is WordPress's biggest audience. I'm not too worried about this audience understanding the PHP side of it, because I want to make it technically unnecessary for them to have to do anything at that level. But in order to best support that audience, I also think there needs to be some abstraction on the code side. I did start out with a structure a lot more like the basic profile. But after working with it a bit, decided to build this in the best and most efficient way I knew how. We're already covering the basics in the default site profile, but don't have anything out there that shows how to build something for larger scale. While this isn't particularly large scale, I decided to approach the profile from a development perspective in the same way I'd approach a site I'm building for a client. Though I'll usually bundle some of this stuff into modules, distancing it from the site templates. I may still do that, but still debating the merits of it in this case. Another factor here is that I wanted to support really easy theme-ability, where you'd never have to make the same change in more than one place. If you want to make this thing run on Twitter Bootstrap rather than Zurb Foundation, all you need to do is replace a few classnames at the top of the file (in the constructor). If you want to make all images follow HTML(5) rather than XHTML syntax, then you only need to change it in one place, and so on for any tag. I didn't want to commit 100% to one CSS framework over another, so trying to keep some things abstracted here so I could swap in another framework without having to change the code. For the sidebar widgets, I'm thinking about taking a module approach for those rather than a template one. That way people could install a new widget (as a module) in one shot rather than having to add a template, add fields to it, and create a page for it.

The term "block" implies generated output or some understanding of what the final output is. PW is meant to be totally markup and output independent so there is no concept of anything relating to generated output. It may be web-based, but the content it's managing might not be. It's the opposite of something like Drupal. I'm not saying the other systems have the wrong approach, because there are benefits and drawbacks to different approaches. But I've been working on this blog profile for ProcessWire the last couple of days and my mind is entrenched in blocks at the moment. I'm not sure if this is exactly what you are trying to achieve, but what you guys are describing sounds kind of similar to the "widgets" sidebar in the blog profile. There is a multi-page reference field called 'widgets' on the homepage. You select (asmSelect) from different widgets (pages) that you want to appear in the sidebar (i.e. Recent Comments, Recent Posts, Twitter Updates, etc.), and then drag them in the order you want them to appear. All the pages in the site inherent these widgets. When other pages in the site have their own 'widgets' field, it gets prepended to the list of widgets inherited from parent pages. Though I'm thinking about making it override rather than inherit, as I'm just trying to find the easiest to understand solution for new users. But regardless of where it ends up, it was pretty easy to setup: // inherit and append widgets $widgets = $page->widgets; foreach($page->parents as $parent) { if($parent->widgets) $widgets->add($parent->widgets); } // output widgets foreach($widgets as $widget) { echo $widget->render(); } I'm guessing this is still different than what you guys are talking about, but figured it might at least add to the conversation since it sounded somewhat similar to what's already been mentioned.

Welcome to the forum Ben! You have to iterate over the repeater, and output each field: foreach($page->my_repeater-area as $building) { echo "<p>{$building->building_description}</p>"; echo "<img src='{$building->building_image->url}' alt='{$building->building_image->description}' />"; echo "<p>{$building->building_text}</p>"; }