ryan

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.

I don't follow Google's algorithms too closely, so someone correct me if I'm wrong on any of this, but I always enjoy talking about it. As far as I know, the words in meta descriptions aren't used at all for ranking purposes, and never have been. But they have a ton of value for user marketing purposes, since that text actually appears to the user at Google. So a finely crafted meta description can be what makes the difference in a user clicking on your site versus another in the search result pages at Google. The same goes for inclusion of keywords in path structure, which get bolded if they match the user's query, marketing to the user in yet another way (even if negligible for actual ranking). You can build a site that performs well with search engines and completely ignore the meta description. But you'll get more people clicking from the search results to your site if you use them well. By that token, the meta description's value can probably be seen as very important from a traditional marketing perspective. But I'm not a copy writer and often don't know how to compel one with words in any special way. So if I (as the developer) don't have the responsibility of writing content, I might prefer to have Google auto-generate one for me rather than trying to auto-generate one at the site. (i.e. omitting the meta description or leaving it blank). Though if there is already a summary or worthwhile sub-head field included with the content, they might be perfect for the meta description. But I don't think there's any reason to be afraid of Google's auto-generated description, unless you really have good human-written content for it. The <title> tags are even more valuable for user-marketing. But unlike meta descriptions they have always carried a lot of weight for ranking. Though if my experience is correct, Google is being even more picky about what it considers a good title tag than it used to. If Google thinks your <title> tag is trying to speak more to keywords than to the user, it's value is reduced. This has always been the case, but I think it's become more so. What always seems to work well is a <title> that forms a focused and intelligible phrase (or short sentence) that reads well to the user and uses a target keyword (or keywords if they read together) in a natural way. These details are the things that we are responsible for and are able to focus on. But ultimately, even if you do everything right on your site, 80% of search performance still has to do with what's happening elsewhere and things that may be out of our hands. Most importantly: what quality sites are linking to you and why they are linking to you. But also: how good and unique the site is (relative to others) and how long it's been around… things that tend to correlate with link quality.

Soma had some good suggestions here. I also wanted to mention I'm planning to include json-text based exports of templates and fields in 2.3, so that you could copy/paste these things easily between sites.

Thanks for testing Diogo and Michael. I'm pretty certain there's an issue in there somewhere. It may not be consistent, but luckily I've managed to reproduce it in one case here so should have enough to go on to fix it.

If it works for you it should be okay. But I think that behind the scenes, it's actually physically deleting a file at some point. Do your filenames change at all when you do this? (i.e. like get a number appended to the end of them) The $image->sort was for our use as a temporary variable. Not actually used by the core. That is just a way to tell the $page that something about the value changed. The $page may not know that the value changed because it's the same object instance (of Pagefiles) that the $page started with. A $page doesn't know all the inner workings of fields it deals with. As far as it can tell, it's still dealing with the same value. Some types notify the page of the change automatically, and it may be the case here too, but I wasn't positive without testing it. So we were notifying the page just to be safe. In my second example, it wasn't even a consideration to do a trackChange() because we actually set a new value to the $page (which it can definitely see).

Spoetnik is correct. if URLs other than the homepage aren't working, then Apache's rewrite engine isn't working for one reason or another. If your .htaccess file isn't there, then put it there in your root directory where ProcessWire is installed. If it is there, then edit it and put some random characters at the top, like "zvljealuiveai" and save. Now reload. If you don't get a "500 Internal Server Error" then Apache is not reading your .htaccess file. The first place to check is your VirtualHost section for the account where ProcessWire is installed in your httpd.conf file. Make sure you have "AllowOverride All" (not AllowOverride None). Save and restart Apache. If that doesn't fix it, double check that you actually have mod_rewrite installed in Apache. Though I'm guessing you do, because ProcessWire would have complained about it during installation if you didn't. Let us know what you find.

That's up to you and your time resources. The simpler you make it for people to install, the more likely it is to get used. I like to make modules as turn-key as possible, so that things can start working without having to do anything other than click 'install'. Obviously, how far that can be taken depends on what the module is for. But if you can safely undo everything with an uninstall() method, then building an install() method to handle installation is good. On the other hand, if it will be difficult to automatically uninstall(), then you may be better off providing good installation instructions (rather than a turn-key install) so that people have a better understanding when/if it comes time to uninstall the module.

What version of ProcessWire and what version of PHP? I've seen this error before, back in PW 2.0 and in older versions of PHP, but don't recall exactly why it occurred, so need to ask questions.