teppo

Answer is long overdue, but I've mostly used this for one-time requests for pages with specific content in specific field(s), i.e. "give me a list of personnel with phone number starting with xxx / email address with domain example.com", sometimes with a twist or two (".. but only those people we mention in one or more of our news items"). Other times I've just needed a simple list of pages matching certain criteria (such as created / edited within given time frame) possibly combined with something like a list of pages they're connected to via a Page field. This is doable via selectors and PHP, but sometimes I just prefer SQL; no need to write even the simplest of scripts or format the output myself (and when formatting, replacing, combining, calculating etc. results is needed, (My)SQL has very good tools for this.) This way I can also add any related data with a JOIN or two, export it as CSV with INTO OUTFILE.. and so on. Most of the time it's just a personal preference, something that makes sense in my workflow and saves me a few lousy minutes of work Note that I've very, very rarely used this at template files or modules -- just a few times to make some common but relatively complex and memory-consuming (from PW's point of view) task faster by cutting some corners -- and it always feels like a very dirty hack. Definitely not something I'd recommend doing.

@Joe: could you provide the version numbers of ProcessLoginHistoryHooks that a) work for you and b) don't work? I'm not aware of any issues related to it, but I'd still like to make sure.. Edit: you mentioned "teppokoivula-ProcessLoginHistory" in your post above. Are you just referring to the module with this name or is this an actual directory in your /site/modules/? Just making sure, 'cause having one module in two locations (such as /site/modules/teppokoivula-ProcessLoginHistory/ and /site/modules/ProcessLoginHistory/) would definitely cause this kind of issue.

This has been discussed about a dozen times already -- not saying that it's not interesting, just pointing out that there's already a lot of discussion and actually couple of (mostly) working examples available if you just take a quick look around

Well, if the module actually shows up as installed, it's most likely still in modules database table. If you can't uninstall properly, try removing related row from there manually. Column class there should match modules classname.

On a mobile so just a quick note that either-or selectors (and this does sound like one of those) are listed in roadmap for PW 2.5+. For the time being I'd suggest finding another approach.

Just to make sure: have you tried removing /site/assets/cache/Modules.* yet?

This would seem to be MySQL issue; one or more of your database tables is broken. I've never had to deal with this particular issue, but this Stack Overflow thread seems to contain some tips on fixing it: http://stackoverflow.com/questions/8843776/mysql-table-is-marked-as-crashed-and-last-automatic-repair-failed. Try googling with the error message (without specific paths) and you'll find other guides too. You'll still have to find out which table exactly is broken, though easiest way to do that might be running repair on all tables starting from something like "pages". Since this does sound a bit "techy", especially if these kind of actions are strange to you I'd first consider re-installing PW (unless there's already a lot of existing data), returning your site from backups (if those are available) and/or contacting your web hosts support (if such service is available). I hope this helps a bit. Please don't hesitate to ask if you need more (or more specific) pointers!

Short answer: this isn't possible at the moment (without hacking core code, which isn't generally advisable.) Longer answer: URL segments obey same rules as page names, i.e. roughly those set by RFC 3986 (URI scheme). You can find some discussion about this here: http://processwire.com/talk/topic/3000-non-alphabetic-page-name/. As you can see here, the behavior is identical whether we're talking about URL segments or pages: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Process/ProcessPageView.module#L141.

@lpa: I was under impression that modules directory was able to get version directly from GitHub, no idea where I got such an idea.. anyway, module version is now updated and modules manager should probably see it too These days most platform-related issues (that I'm aware of) have been between OSX and Windows, Windows and Linux, Android and iOS and so on.. not so much between different versions of same platform. Generally speaking IE8 has same issues whether installed on Vista, Win7 etc. This is why I didn't feel that OS version would really matter. The module is already collecting UA strings, which can be used to identify not only platform but also it's version. It' a bit tricky, though, but I'll look into adding this feature. PS. "Please note that the inflight internet is only available when the plane is above 10,000 feet." I did *not* know that wifi could work this good on a plane.. miracles of modern (at least to me) technology, I guess

What I meant by that was that the RTE module wouldn't have to be updated separately of PW itself. Updating PW is usually just about as much work as updating each individual module (not to mention that it's the one thing even I tend to keep always up to date, as it's super rare for core updates to break anything.) You're of course right in that modules manager would make things easier. If it was a core feature this "easy update" argument would be almost entirely invalid.. or, to be honest, almost everything I've mentioned here so far in favor of bundling an RTE This is a bit off-topic, but I'd actually prefer PW to have more modules manager features built-in. Obvious downside is that especially newcomers may have hard time evaluating whether particular module is of high enough quality for their needs. Generally the quality of PW modules is very good, but there are exceptions to this rule too. Perhaps we need new "Ryan seal of approval" badge that could be granted for modules that fulfill certain criteria and only those could be auto-installed?

Morning Joss! That makes sense, though from my point of view there's also some very real value in having built-in, always up-to-date RTE coupled with PW. Again I'd like to stress that decision like whether or not something is a part of core should depend on what's best for most users. If a module is something that all (or almost all) users need and/or use, I really think it should be included with core package unless there's very solid reasoning against that. Having it as a part of default site profile is almost as good, only real difference being that users would have to keep it up-to-date manually. But then again, if the real issue is that it's not configurable enough, wouldn't it be better to focus on improving it's configuration settings instead..?

@Joss: I guess it boils down to what most users need. RTE (or WYSIWYG, though the term itself is bullshit) has, in one way or other, been a part of each site I've built within last ten years (those that have included any kind of CMS capabilities at least). I'm sure that's not true for everyone, but if that's the case for most users then I think we should definitely have one built-in. @Martijn: I'm afraid that this would only be helpful for couple of modules. These days there's also a lot of speech about ditching browser sniffing in favor of checking specific capabilities (though I don't fully agree with that -- it sure helps when you're checking for features, such as geolocation support, but not actual bugs). @Pete: downloader would be awesome, but that wouldn't help us who prefer to clone latest version directly from GitHub. In any case I really think that such a tool would be nice addition. CKEditor site has pretty sweet implementation of this already: http://ckeditor.com/download

@lpa: IP address logging is added now. Grab latest version from GitHub and you should see new "Log IP addresses" option in module settings for Process Login History Hooks. This isn't enabled by default to avoid some possible (though probably quite theoretical) legal issues. I know that most servers already gather IP addresses of visitors, but one might argue that being bundled with other data that this module collects makes those more likely to be considered "personal information", which in turn may require additional statements on the site itself etc. Edit: forgot to mention that I'm still wondering if collecting OS version is really useful. If you (or someone else reading this) can provide me with some examples where that data would be useful I'm all ears

Joss: I think I was being a bit too vague there Did you mean that it would actually be in default site profile's modules directory or still bundled with core modules, only not "permanent", or something else? I'm not sure if this would really be beneficial compared to current situation -- seems to me that the biggest issue with having TinyMCE and/or CKEditor built-in is that they're actually pretty damn big (TinyMCE 4.3M, CKEditor whopping 14M).

Peter: just to make sure, was that script block before InputfieldImage.js but after jQuery.js? Just checking since you mentioned that you moved it before "other" files.. Any chance that you could put this somewhere we can see it in action? That would be very helpful.

I seem to vaguely remember someone saying something about decoupling TinyMCE from core at some point. (Emphasis on "vaguely"..) Personally I wouldn't mind TinyMCE not being included with core, especially since I haven't really used it since CKEditor module came out, but I'm wondering if not having "built-in" RTE in ProcessWire might give bad impression to some folks just getting used to PW -- even if it's available as a module? I'm probably just overthinking this, though.

Peter: most likely issue is that "inputfieldFileLink" trick is done at InputfieldImage.js, so it happens before you add the classes and thus won't find anything. Move the custom script block (one containing .addClass()) before InputfieldImage.js and this should work better. Also, I'm guessing that you viewed source via browsers "View page source" tool? If so, that won't take any JS modifications into account -- make sure you use native dev tools or something like Firebug when debugging JavaScript issues.

Slight variation to what Martijn suggested above, you may want to make sure that only local images are affected: $('a[href*="/assets/files/"]:has(img)').addClass('InputfieldFileLink');

@SteveB and @ryan: good point about deleted pages, this is now taken care of. No idea why I didn't think of this earlier.

Not hard, just inconvenient. CKEditor in inline mode is comfortable enough to finally make writing with RTE in browser comparable to writing in text editor. Having one go-to tool instead of two feels slightly better. This is very much a question of preference, so there won't be any "correct answers" here -- some users prefer to write at Admin and others will probably always write with Word, Notepad, Notepad++ etc. AdminHotKeys is only partial answer to saving issues mentioned here, unless I'm missing something: it still requires reloading page, which (especially when working with crappy connections) can a) take ages and b) result in timeout and lost data if you're not careful. Isn't that exactly why we're discussing background save methods here? One more thing to note is that any autosave / background save feature will also need to handle exceptions (such as being momentarily disconnected) properly, otherwise they could even make things worse; user must know what's happening, when last successful save occurred, whether there are connection issues etc. Basic stuff, but very important nevertheless.

About a week ago I wrote a blog post while on train and some odd hiccup -- not sure if it was connection issue or just something I did wrong as I was using a tablet, which is far from perfect tool for this job -- but the whole post simply disappeared. Needless to say, I wasn't very happy. Sure, I should've saved more often, so it was really my mistake, but that was still an example of a situation where autosave would've saved the day (quite literally.) My needs are quite simple so I'm currently thinking of writing a very simple module for that purpose alone, but it's good to see that others are toying with similar ideas here. My issues are pretty far from a full-featured "save as draft" solution, but still

This is pretty much how I'd solve this, still no need for any core changes or additions Create new template called "symlink", add page type field "symlink" with value limited to single Page (use PageListSelect as input field type) and then in template file do something like this: <?php if ($page->symlink instanceof Page && $page->symlink !== $page) echo $page->symlink->render(); else throw new Wire404Exception(); Now you can add as many symlinks you wish and easily choose which page each is tied to. Don't forget to add canonical tags to let robots know which version of this page is the "original" one, though, or you'll have serious SEO issues.