teppo

In addition to that, if you really just need to save one field, you can always use $page->save("my_field"). Logic (change tracking etc.) behind it is a bit different, but it's also usually faster. Not that it would, in most cases, really matter Edit: by the way, it looks like Ryan's example is about creating new pages with a custom frontend form? If you want to edit one field of current page, it's a bit easier than that; no need to create new page etc. as you can simply set value from $input->post->my_field to $page->my_field and call $page->save() (or $page->save("my_field")). Don't forget to use $sanitizer, though..

I don't have definitive answers either, but it sounds a lot like you're not doing something properly; what do you mean by removing install.php, are you trying to install PW "manually" without it by simply renaming site-default directory to site and adding DB config to site config? If that's the case, I'd double check that you're actually doing everything install.php does for you, i.e. importing site SQL, creating superuser account etc. Another thing to note is that MySQL password limitation you mentioned has been fixed in dev branch, so I'd strongly suggest that you try installing it instead of master branch. It's quite stable already (I've been using it for my own site for months without any serious issues) and contains many small fixes and some very nice additions too when compared to master. Edit: if this doesn't help, posting the DB error you're getting would be very helpful. Without that we can only guess what could be wrong

@Joe: I'm not entirely sure if there's something helpful there, but Aloha editor and integrating it into PW was discussed in the Adminbar thread some time ago and Ryan even provided some sample code that might be helpful. You might want to check that discussion out.

First of all, robots.txt needs to be in your site root (not /site/, but before that) to work properly. It's also possible to place it somewhere else, but then you'll have to find a way to make your web server serve it from site root, which can get tricky, depending on your web host and it's capabilities. I'd go with root to keep things simple. Favicon can be placed somewhere else than root, but root seems to work best as some browsers look from there automatically. I'm not sure how many browsers do this on their own, but the link tag is definitely recommended. Probably the only way to make sure that your favicon is found is a) placing it in the root directory and b) adding link tag pointing to it. Edit: Wikipedia provides some details about how different favicon settings are interpreted. This seems to support what I said above, i.e. placing favicon in site root and adding link tag, though that link tag is at least partially optional (I'd still leave it to make sure, though.)

Joss: if you have the time, it would be helpful if you could post the URL you used -- it's always possible that regexp is missing something. This module needs some improvements (in more than one front) soon, and it'd be great to sort out any existing bugs first

I'm not sure if anyone has (yet) tried building such a construct with PW. Personally I'd be very interested in hearing how it goes, so please do keep us posted if that happens -- but still, if I had to do this for a client, I'd consider what @dragan said above, i.e. using custom database table for this data. ProcessWire is efficient, but when dealing with simple, fixed-form data (and huge amounts of it) custom database table is going to have performance benefits. This, in turn, translates to cost savings, which probably neither you or the client would be against Dragan's point about archiving old data is very important too.

Sounds like your web host has some sort of caching enabled -- if you're using managed hosting, web hotel etc. I'd suggest taking a look at the help materials available and possibly asking the administrator(s) what could cause this. If you're hosting yourself.. well, you should know best what's installed and running

@kyle: in case that this is related to creating files on the disk, have you considered installing SessionHandlerDB, i.e. moving sessions to database? If you can't log in to install it, you can do this with a very simple external script: <?php require 'index.php'; // path to PW index.php wire('modules')->install('SessionHandlerDB');

@Martijn: search engines have surely improved their algorithms a lot, but there are still things that are pretty hard for them to get right. One of these is whether alternate content is really relevant to the visually impaired, another is the general subject of usability. Sure, page speed matters, but what about totally unusable navigation, unreadable font face or inconsistent UI in general? Personally I'm a big fan of trying to analyze just about any data and making educated guesses about how good it is for purpose x, but I don't think we're quite there yet. According to some experts "human factors" are nowhere near the top of the list, at least. "Social" factors sure are, though in a different meaning than what you probably had in mind.. (Actually above link kind of seems to suggest that alt texts are considered good for SEO if they contain important keywords already visible in other content. This doesn't sound like a very good thing to me, as I fear it only encourages people to use them to repeat same things they've already mentioned in body content and headlines, which in turn doesn't necessarily imply any correlation with them being useful to the visually impaired.)

Looks like MariaDB is gaining some momentum. Red Hat going with MariaDB instead of MySQL is pretty big news for a lot of companies out there.

Technically speaking I've got nothing to add to above, but I couldn't resist commenting on one point here: alt text is not for "SEO guys." Please don't use it that way. Ever. The whole purpose of alt text is to provide meaningful alternative content for those who can't see your images -- using it to insert extra metadata for robots is very, very wrong. Sorry for the rant, but this is such a common usability fail that it's getting annoying; way too often alt texts are used either for SEO purposes ("hey, let's consider robots before humans!") or entirely useless metadata (a picture of a cat with alt text "a cat".. was that really useful for someone who can't see the image?)

@apeisa: using IE9, I'm seeing a whole bunch of JS errors when loading edit views with Adminbar. Not every time, but couple of clicks on the edit button and there they are. Any idea what could cause this? SCRIPT5009: 'Array' is undefined JqueryCore.js?v=183, line 2 character 9220 SCRIPT5009: 'jQuery' is undefined JqueryUI.js?v=192, line 6 character 2 SCRIPT5009: '$' is undefined ProcessPageEdit.js?v=102, line 1 character 1 SCRIPT5009: 'jQuery' is undefined JqueryWireTabs.js?v=103, line 8 character 2 SCRIPT5009: 'eval' is undefined JqueryFancybox.js?v=126, line 16 character 2 SCRIPT5009: '$' is undefined ProcessPageList.js?v=102, line 16 character 1 SCRIPT5009: '$' is undefined MarkupAdminDataTable.js?v=101, line 1 character 1 SCRIPT5009: 'jQuery' is undefined JqueryTableSorter.js?v=203, line 2 character 2 ... CKEditor could be part of the answer, as this is one of our first big sites with it enabled. These errors don't show up when loading same modal edit view in it's own tab/window, so I'm guessing the iframe embed might have something to do with this too. Also: in IE9 this seems to stay at the level of ton of errors, but a client has reported that on IE8 whole view simply freezes and nothing works. Again, not every time, but often enough to make it an issue. Edit: actually this also seems to disable most features (links, lists etc.) in CKEditor (IE9.)

Joss: is the URL inside that <p> tag plain text or a link? CKEditor has the habit of creating links automagically. If it's a link, try making it plain text and see if it works then. That's probably the most typical issue with both this module and some other textformatters. Another thing you should make sure is whether any other textformatters are placed before this one. Conflicting textformatters is quite a common issue too. Ones placed after this one shouldn't matter, but it depends a lot on what they're doing.. If the issue is neither of those, I'll try to take a closer look at this soon. In that case a short excerpt from your final source (output) would be helpful, i.e. to make sure that it's not something weird related to tabs, spaces etc.

@arjen: just to make sure the issue isn't related to the URL (shouldn't, but who knows), I've added alternative address for the feed: http://www.flamingruby.com/blog/feed.xml If you have time, I'd appreciate if you could try that one out and see if works any better. I'll probably try to debug this myself at some point too, as I've had similar issues earlier with some feed readers. It's not much of an issue on my own site, but on a client site.. well, let's just say that it would be nice to know what's causing this before that happens

Seems like a bug. Could be related to this issue reported earlier -- looks like Ryan hasn't applied a fix for it yet.

@arjen: feed should exist already, see http://www.flamingruby.com/blog/?view=rss Edit: there's also an "alternate" meta tag at /blog/ pointing to that URL, so it should usually be enough to provide the blog URL (not sure how different readers behave regarding these, though.)