teppo

@Julian: since PW is simply using MySQL NOW() function, I'm guessing that your database has different opinion about correct timezone than PW. Typically it would be using the server timezone, but that's not entirely certain. This Stack Overflow thread contains some tips that could prove useful here.

Just a quick heads-up: like you've already pointed out above yourself, you really shouldn't do this, as it seems to open a ton of new security issues. There are probably even better ways to do it, but why don't you at least create a new page (or Process module) and use PW API to handle the saving? It should be pretty straightforward, i.e. something like this: <?php if ($user->hasRole('admin')) { $target_page_id = (int) $input->get->page; if ($target_page_id) { $target_page = $pages->get($target_page_id); if ($target_page->id) { if ($user->hasPermission('page-edit', $target_page)) { $content = $input->post->content; $target_page->of(false); $target_page->body = $content; $target_page->save(); } else throw new WireException("Permission issue"); } else throw new WireException("Page not found"); } else throw new WireException("Missing page ID"); } else throw new WireException("Missing role"); Generally speaking, whenever you find yourself fetching (or, even worse, storing) data to/from native PW database tables, it's likely that you're doing something wrong (Exceptions above exist mostly to demonstrate couple of things you'll want to take care of if you do this at template level. Process modules have their own method of handling permissions, which makes that part less complex. Note that this was written in browser and I've no idea if that code works straight away, but I hope you'll get the point..)

@pwired: depends a lot on your needs -- whether you're just hosting the development environment etc. Self-hosting development environment is doable, but I wouldn't really consider hosting production environment for any other use case than in a small company working with couple of smaller clients myself. Once larger clients, SLAs, HA-requirements etc. enter the picture, simply managing the infrastructure is going to require full-time employee (with proper skills, not just a developer with rudimentary *NIX experience) working on it and being on call 24/7, which can get expensive. I've also seen clients require that the environment be set up in multiple geographical locations, be guarded from physical theft and natural disasters, be able to survive DDoS etc. -- not necessarily something you'll want to (or even be able to) handle yourself. Another important thing to mention is that when you're using cloud-based solution you'll typically pay for what you use, not all those extra resources you'll need to have with that self-hosted alternative just to survive short-term usage spikes etc. You also don't need to worry about periodically upgrading your machinery and won't necessarily even have to commit to a long-term contract (further decreasing involved risks.) All things considered I'd say it's pretty damn good deal, actually

I must say that I agree with both views here; what Martijn described is definitely a nuisance and I really wouldn't mind if Soma decided to change it, but it also feels that it's just wrong (and inconsistent) to have fields behave in different way when used in module settings context

I work on multiple devices, ranging from phones (rarely) and tablets (not so rarely) to desktop machines. Having everything properly set up no matter what device I start (and no matter whether I've ever even used it before) is cool. I'm also most productive when I don't have to spend time adapting to new environment every time I start different machine, so having a consistent experience would definitely be a big plus. Personally I've solved most of these by having everything set up server-side, making browser and SSH client (and, though that's apparently going to change pretty soon, Photoshop) only things I really need to start working and be productive. Nevertheless I can see why some people might not like that and would actually prefer some horrible mouse-driven graphical IDE and other similar productivity killers.. From company's point of view, on the other hand, this just makes sense; not only does it make new kind of collaboration possible (like Joss already pointed out) and (theoretically) even make moving people from one project to another a breeze, it can also decrease costs of each new employee. No more high-end Macs, pricey IDEs and self-hosted complicated environments when all you need is couple of cheap thin clients and web-based, monthly billed app. That, and the (sad) fact that when that environment is developed far enough your employees don't really even need to know what's happening behind the scenes (Git, whatsthat?) when everything just magically works. Lower requirements when hiring new people often equal lower salaries.. and each new guy takes shorter time to learn the ropes and start being productive. I could list a dozen or so other benefits, but I think this pretty much summarizes it

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.)