ryan

In your getModuleInfo() method, delete the "'permanent' => true" line, as that only makes it impossible to uninstall the module (which we only want for select core modules). In your init() method, you are adding a 'toJSON' method to the $pages API variable. But your pagesToJSON() method appears to be written like it's meant to interact with a PageArray. As a result, I think the problem is that you need to change your hook like in the init() method to be this: $this->addHook('PageArray::toJSON', $this, 'pagesToJSON'); I am guessing that the source if the error is that you are trying to call toJSON() on a PageArray when it's not hooked there. Hopefully the above change should fix it.

I think you'd need to be more specific in your question and give this context: What will you sell (products, services, e-books, etc)? Will your store need to handle taxes and/or shipping? What payment types do you want to support? What countries are you selling in? Are you subject to PCI compliance? Have you ever managed an e-commerce site before? There is a ProcessWire ecommerce module that @apeisa has built and is building, as discussed in this thread. While I am not an expert on that module, your answers to the above questions may help others to make suggestions as to whether that module would be good for your needs. If you find you can't answer all of the questions above, or don't yet have any e-commerce experience, then my suggestion would be this: Regardless of what CMS you are using, use an e-commerce service rather than trying to run your own. It's one of the most complex online applications, especially with PCI compliance, shipping, and taxes. Personally, I use http://shopify.com and am happy with it. Another user here mentioned they are happy with http://lemondstand.com . Many of these services (Shopify at least) include web hooks that allow you to trigger actions on your ProcessWire site (like creating subscriber access, for instance). This opens up a lot of power without requiring a lot of work or expertise about ecommerce on your part.

I would probably make current_team a single page reference, and past_teams a multi page reference. Meaning, two separate fields. Lets say that $team is a Page with the current team. A team could find it's current members like this: $riders = $pages->find("current_team=$team"); and past members like this: $riders = $pages->find("past_teams=$team"); I know I said before that I didn't think there was a place for repeaters here. But now I take that back. Here's an alternate approach that might be handy by using repeaters: You could setup a repeater called 'teams' and have it contain these fields: team (single page reference) year (integer or page reference) Then you could find all current members like this: $riders = $pages->find("teams.team=$team, teams.year=2012"); and past members like this: $riders = $pages->find("teams.team=$team, teams.year<2012"); The other option you mentioned: retired checkbox with first or last being current, also seems like a fine way to go. But that does make it harder to quickly differentiate between current and past teams, at least from the context of $pages->find(). So I think it may be better to use one of the options above. If you use the repeater approach mentioned above, you could add a checkbox to the repeater that indicates they are a participant. So if you wanted to find all partipants (the 6 rather than the 15) for $team in the year 2012: $participants = $pages->find('teams.team=$team, teams.year=2012, teams.participant=1"); Lets say you wanted to output a table like your example link: http://www.cqranking...r.asp?riderid=7 Here's roughly how you'd output that: $rider = $pages->get("name=lance-armstrong"); foreach($rider->teams->sort("-year") as $team) { echo "<p>"; echo "Year: {$team->year}<br />"; echo "Team: <a href='{$team->team->url}'>{$team->team->title}</a><br />"; echo "Participant: " . ($team->participant ? "Yes" : "No"); echo "</p>"; } Should give you a result like this:

Thanks Pete, good to know about the difference there. That definitely explains why Cufon goes soft on the retina screen (iPhone at least). I will make a point to avoid Cufon.

@pete: it stores the target as the page ID rather than a URL so always going to redirect to whatever is the Latest ver of the page. (ie no extra redirects) @diogo: it doesn't look for redirects unless a 404 has already been triggered. So if the requested path matches a page in the system, a 404 never gets triggered and this module would not come into play. @WillyC: please try that out and report back what you find?,

We'll use this thread to discuss PW 2.3 features as they are being worked on. I've just added one of the first components. This is the "Page Path History" module. It's now in the PW core as a beta module (uninstalled by default). If you are interested in helping to test, just install the module from Admin > Modules > Page > Page Path History (after doing 'Check for new Modules'). The Page Path History module keeps track of the previous URLs for any pages that have been moved or renamed. It then sets up automatic redirects (301, permanent) to ensure the old URLs redirect to the new ones. This is best demonstrated by a few examples: Lets say you had the page /about/contact/ and you moved it to /contact/. With the Page Path History module installed, anyone accessing /about/contact/ will get redirected to /contact/. You had a page called /our-products/ and you renamed it to be /products/. Any accesses to /our-products/ will now get redirected to /products/. Those are simple examples, but this module can handle more complex situations too: Lets say you had the page /our-products/furniture/whoopie-cushion/ and you did like in the previous example and renamed /our-products/ to be /products/. The /our-products/furniture/whoopie-cushion/ URL will now redirect to /products/furniture/whoopie-cushion/ Later on you decide to rename /products/ to just /inventory/. All the /our-products/ and /products/ URLs will continue to work with redirects. You decide that whoopie-cushion really belongs in /services/ rather than /inventory/, so you drag it to /services/whoopie-cushion/. It's old URL in /inventory/furniture/whoopie-cushion/ redirects to it's new URL. TL;DR (am I doing this right) -- you can move or rename any pages and all the old URLs will redirect to the new, automated behind the scenes, without any thinking on your part.

Great post! PW is a lot different than Drupal in this regard, but no less flexible. Between page references, structure, the API, and markup under your control, I think you can take PW further than you can Drupal. Another aspect of PW that I wanted to mention that is easy to miss: PW supports unlimited granular permissions. You can simply add new permissions in the admin (Admin > Access > Permissions). Then edit any roles you want to have those permissions and check the appropriate boxes. From that point, you can use those permissions in the API however you want. For instance, if you'd created a permission called "sugar-in-coffee" then you could check if the current user has that permission by using the API: if($user->hasPermission("sugar-in-coffee")) { // do something } Something else you may find handy is if you want to provide additional access without a user having to login. Lets say you are performing some check with the IP.Board API to determine if a user of a certain level is logged in there, and you want them to have upgraded permissions in PW at the same time. Create a role that has the permissions you want. Then you can assign that role to guest when you detect they should have additional access: if($user_is_logged_in_ipboard) { // or however you perform this check $user->addRole('member'); // where 'member' is the role you added // now user has more access } or if you want to login a specific user in PW, but don't need to authenticate (because they already authenticated in IP.Board): if($user_is_logged_in_ipboard) { $u = $users->get($ipboard_user_name); if($u->id) $users->setCurrentUser($u); // now a user is logged in for this request, without having to authenticate }

Thanks Pete, I will check this out. Right now I'm just trying to keep it consistent with Nikola's Futura theme, so it's using the exact same assets (Cufon, in this case). I don't even know what exactly Cufon is to be honest, I just copied it from his admin theme. However, each theme can have it's own assets, so there is no connection or dependency of Cufon to the blog profile. We won't standardize on any particular font system for the blog profile just because it's theme specific rather than profile specific. But I will definitely look into bringing in FontSquirrel into the next theme I make for it. One negative that I did notice about Cufon is that the fonts look pretty soft on the retina display, relative to all the other text. Not sure if this is a problem with other font systems or not, but just observed this about Cufon. Hold off on digging through it, because I have to post the new version. The one currently posted is very old at this point.

I agree with what the other guys said, but also wanted to add a note about the statement above. Since the rider belongs to one current team, you could make their parent page their current team, and have a multi-page reference reflecting their past teams. However, if these things will ultimately be public/indexable web URLs, then it's better to keep them in permanent spots in the structure and use page references for everything. That way the same URL can always access the same rider, regardless of time. Does something like a nationality ever change? If not, that may be a suitable parent for riders. I like having some structure where possible, rather than using page references for everything, but if everything can change then only use structure if changing URLs are acceptable (usually they wouldn't be). So far I'm thinking that you won't need/want to use repeaters for any of these needs. This sounds like a fun project. Especially with the Tour on now.

Actually I was using it for the Blog profile. I was using it so that you could select from what "widget" modules you wanted to display in the sidebar and sort them. The widgets were markup rendering modules. However, I went back to making the widgets as pages (selected as page references), as I thought it was ultimately more flexible. So in the end, I'm not using this module for anything. But think there will be other situations where it is useful.

Thanks for adding that Pete, it seems like a nice addition. Those are some smart line numbers too! Somehow they manage to avoid being copied/pasted. Most sites don't do this, I've been annoyed many times copying/pasting bits of code only to have to clean out all the line numbers that pasted. No such problem here--nice

I'm excited to hear about your new admin theme! I've taken quite a liking to Futura and have made a Futura front-end based on your theme for the new blog profile: http://processwire.com/blogtest/?theme=futura -- am I missing the mark with any of the details?

That's great Sinnut, thanks for posting that there! Seems like a good place to start. Now I need to make part 2 of that tutorial

This probably won't be useful to most people, but this is a module I put together a couple weeks ago for my own needs. I thought it might be helpful with a question that came up in another thread, so just wanted to post it here too since I figured all the modules should be listed here. ProcessWire Modules Fieldtype Fieldtype that stores reference to one or more other modules. This is similar to FieldtypeModule except that it stores multiple modules. It uses asmSelect to make the selection sortable/searchable. To install Copy to /site/modules/ and go to Admin > Modules > Check for new modules. Usage notes Note the configuration settings that appear on the details tab when creating a new field that uses this module. Lets say you created a field called my_modules that uses this Fieldtype. The value of your $page->my_modules will be a PHP array. When $page->outputFormatting is TRUE, the values of the array will be selected module objects (already instantiated/initialized). When output formatting is FALSE, the values will be module IDs (integers). Those IDs can be converted to either the module class name or an instance of the module using existing $modules API methods. Download https://github.com/ryancramerdesign/FieldtypeModules

Not sure if this is helpful to you guys or not, but here's a module that stores multiple sortable module references (rather than just 1 module reference): https://github.com/ryancramerdesign/FieldtypeModules

That's a good point--I hadn't actually tried images on the RSS feed before. Here's another way you could do it: $contents = $rss->renderFeed(); $contents = str_replace("<img src=\"/site/assets/files/", "<img src=\"http://clintonskakun.com/site/assets/files/", $contents); header($rss->header); echo $contents; This problem should resolve itself in 2.3, as I'm planning to abstract URLs to IDs in textarea fields. The IDs will be resolved to the full URL at render time.

Great thread. Beyond the PR text we've written and submitted to other sites, I haven't seen a lot written about PW. Most of our buzz pops up in forum threads about other CMSs, comments to blog posts about other CMSs, and on Twitter. This is all great of course. But when someone searches on Google for independent articles on ProcessWire, the majority of results are just our press releases on other sites. Here are a few articles I'm aware of about PW: Marc Carson has written some great things about PW on his site, like this and this and this. Clinton Skakun has written a lot of good PW articles. Like this one and several others. Though there may be occasional statements I don't think are 100% correct, but really like the effort and enthusiasm he's putting into writing about PW. There are some nice ProcessWire reviews on alternativeto.net

The considerations I mentioned about email verification with the comments are good reasons why PW doesn't do this by default. Things like that get taken advantage of when they are a default behavior that can be exploited across many installations. But in your case, it's less likely someone will be taking advantage of it given that yours be unique. If you really need to verify that the poster matches up to a specific email address, you would have to do email verification. So I think that if I were in your situation, perhaps I would go ahead and do it, as the benefits outweigh the drawbacks in your case. PW works nicely with comment services like Disqus and Intense Debate, so you may want to investigate the options there. But if you want to stick with using PW's built-in comments fieldtype, I think your best bet is to modify the one it comes with. I'm not sure exactly the strategy you'd want to use here, but what you mentioned about adding another status may be a good one. Though if compatible with your needs, I might just reuse the existing Comment::statusPending and have the email confirmation convert that to Comment::statusApproved. If combining with Akismet, you may want to manually handle any comments that get labeled as spam, or perhaps have the email confirmation move them up one level from Comment::statusSpam to Comment::statusPending (where they would be manually approved). Email me at ryan at this domain if you would like me to custom develop this for you. Or if you are comfortable on the PHP side, I'm here to help in the forum if you have any questions that come up along the way.

Here's an update on the blog profile. It now supports themes. The first theme I've made for it is based on Nikola's Futura admin theme: http://processwire.com/blogtest/?theme=futura I've also made a ProcessWire theme, but I think it still needs work (a little too girly right now): http://processwire.com/blogtest/?theme=processwire I'll probably put in one or two more themes for the distribution version. You can select the theme from the homepage. It's just a page reference field where it lets you select from pages using the "theme" template. The "theme" template is nothing more than a files field with all of the theme's assets in it. Typically this would be a CSS file(s), JS file(s), and images or font files (if used). I also had color pickers for defining the themes colors, but backtracked on that. I want themes to be self contained so that can create a new "theme" page, drag a ZIP file into the page, and be done with it. Once color pickers get involved, it becomes much less portable. Though I may still provide the option for overriding theme colors, but I have a feeling most people would prefer to just edit the included CSS file and then drag it back in. This version also is better optimized for mobile use. In addition to converting the top navigation to a <select> in mobile views, it now moves the search box and any other navigation to the bottom. That way people on mobile should still see the primary page headline and some of the copy without having to scroll.

I think it's a useful idea, but you do have to be careful with something like this. Anything you put on a server that enables a public form to send out email to a user-specified address is something that can be attacked. Even if they can't control the contents of the message, they can use it for getting you on blacklists, getting you in trouble with email laws, DDOSing/consuming server resources, or annoying a large group of people. Some who like to take advantage of this stuff can do so through proxy servers, so it's not possible to protect against 100%. I personally think that using a filter service like Akismet is the safest way to go. But if you still want to do email vertification, you'd probably want to modify the comments modules directly. But before you do that, I want to find out a little more about your situation: are you getting hit with lots of spam? What kind of quantity? I may have some other ideas we can explore.

I think that site is worthwhile and adds value so long as the info is original and safe. I like that what he's put there so far is good info for the most part. For instance, I like that the recent contact form post isn't just another contact form, but one that integrates use of recaptcha with it. I did have some corrections for him on that, replied to in the comments, but did like seeing this different approach for a contact form. Also thought he did a good job with the SEO tricks article. We setup the Wiki for this purpose a couple months ago (http://wiki.processwire.com), and I'd rather see this sort of content grow from there. It's wide open for anyone to contribute. But so far, no action there (other than some occasional spam I've been cleaning out). I don't know how to motivate people to contribute in that respect. People to write this stuff are few and far between. So even if it's not under the processwire.com umbrella, I like to see that Clinton is going out there and writing stuff. I support just about anything that helps to communicate ProcessWire to a broader audience. My only concern would be (like Antti mentioned) incorrect info that we don't have the ability to fix--that potentially increases our support burden. But I'd rather have people write than not, so think it just goes with the territory. Overall it's just great to see the enthusiasm for ProcessWire. More sites talking about it in depth is probably a good thing for growth. Not positive, but I think he might have been talking about the quantity of files/directories included with a PW installation (i.e. under /wire/)? So the upload/download time might be related to migrating a site from dev to live? Though the info is probably still incorrect as PW is pretty lightweight compared to most CMSs in this regard. But we do have the likes of TinyMCE and others that contribute to quantity of files. I use rsync for migration which makes things happen in an instant, but I have seen some FTP clients that pause between every file, and a few slow FTP servers that pause between files. So something like migration speed is probably speaking more to the web host, connection or client. If one has to deal with any issues here, something like quantity of files becomes a factor in migration speed.

Most sites [that I make] rely on good photography to carry a lot of design weight, making the job easy. But in this case, you've had no such luxury... there's even a pic involving a toilet on the homepage. This is quality design carrying all the weight of making things look good, and doing so really successfully. Beautifully designed and executed--nice work! Also really like the detail of photos zooming on hover.

Unfortunately I don't think that file fields can be nested beyond one level of repeaters. There is some necessary security going on behind the scenes that limits the scope of how deep an ajax request can go, and I think that's what you are running into here. The truth is that you may actually be able to get it to work if it weren't using ajax uploads (like if you were using Safari, which doesn't support ajax uploads). But I think you may be better off avoiding nested repeaters if possible. Nested repeaters are a rather complex thing to develop around and may be difficult to maintain vs. a simpler solution that doesn't rely on nesting. Still, you've got me curious and I do plan on experimenting here and trying to duplicate the next time I'm working with repeaters, just to be certain I'm right about the reason it's not working. If there is an easy way around it, I'll find it. Nested repeaters do sound fun. But either way, for practical purposes, I don't think it's good to build around a structure that requires nesting repeaters.

Thanks for posting back what you found. It remains a mystery for the moment, as I don't know how the changes you made could account for the error it fixed. But if what you did seems to have fixed it, then I also don't see any harm in it either. Please let me know if you come across a similar situation in the future. If possible, I'd like to get access to it so that I might be able to open the hood and see what's really happening in the engine room.

ProcessWire can be a great back-end for any kind of user data management needs that you have. But since we're shy about generating markup for your site(s), you won't find non-administrative user and account features like you would in something like Drupal. When it gets to those kinds of things, ProcessWire takes more of a framework (CMF) role, giving you tools to manage data for the things you build. If you are building a site centered around things like user registration and profile management, you may find something like Drupal worth putting up with in such cases. But if you are like me and several others here, you'd rather build these things yourself in ProcessWire, so that you can maximize control over the function and output of them. Should you want to do it, we are here to help you through it and answer any questions as you go.