teppo

@Sevarf2: no native way (that I'm aware of). In case tat you're using Session Handler Database (i.e. storing sessions to database instead of files) table "sessions" will contain all active sessions and theoretically you could get distinct user_id's from there and then find users matching those. These users may not actually be actively doing anything or even really be online, they just haven't logged out yet and their sessions haven't been cleaned by garbage collector. Sounds kind of hacky, but it's a start..

I'm not entirely sure how much sense this makes, at least without some additional changes; at the moment if you make a fieldset global, you still can't insert any fields in it by default, right? You'll just have an empty fieldset with all your templates? Option to make a fieldset global and choose which (global) fields it should contain and their order would be pretty awesome, though.. (By the way, there's a full section of this forum dedicated to new ideas and suggestions like this: Wishlist & Roadmap.)

Thanks, Ryan -- looks like we were too impatient

I'd like to point out (again) something I mentioned earlier: Removing "permanent" status from TinyMCE would take us past at least some of the issues mentioned in this thread; that way anyone could simply uninstall it and then install another RTE or none at all, whatever they prefer. Bundling it with site profile instead of core is, again, almost as good -- though personally I dislike the idea that pretty much every site profile out there would need to include an RTE after that. Sure, they could choose one of their own instead of what default site profile uses, but still @ryan: sounds like it would make most sense to combine the switch to TinyMCE 4 / CKEditor with release of either 2.4 or 2.5 (depending on your timeline here), especially if there's a possibility that existing fields don't work as expected after upgrade? Regarding differences between TinyMCE 3 and 4, they do provide "compat3x" plugin to make transition less painful. Might be worth checking out if issues mentioned above were somehow related to plugins.

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