teppo

I'm getting this right now (right after updating from 2.4.3 to 2.4.5), so it's definitely an outstanding issue. Will have to dig in to see what's going on.. Edit: Just guessing, but could this be related to this commit and the part about "6) Convert Fieldtype modules to load on-demand rather than all at boot"? Looks like after the update when InputfieldCropImage runs, FieldtypeCropImage hasn't been init'd yet.. which obviously results in getThumb() not being available. Anyway, will have to debug more. Edit 2: Whether or not that was the issue, I've solved it locally by making sure that FieldtypeCropImage is loaded with InputfieldCropImage. I can't uninstall the module or try other tricks on this site, as it's already in production -- I'm assuming that Antti or Ryan will dig out the real reason (and fix) for this, but in the meantime this works for me: Index: InputfieldCropImage.module =================================================================== --- InputfieldCropImage.module (revision 7702) +++ InputfieldCropImage.module (working copy) @@ -13,7 +13,8 @@ public function init() { parent::init(); - + // make sure FieldtypeCropImage is loaded + $this->modules->get("FieldtypeCropImage"); //default settings $this->set('thumbSetting', 'thumbnail,100,100'); }

@Joss: it's also a matter of knowing your customers. Being in the same channels and not forcing them to use the channels you've chosen. In this regard I appreciate what ServInt were trying to do, i.e. using Twitter and Facebook to communicate to clients already in those medias. What they failed at was that they sent out one quick message, neglected keeping people up to date as things evolved and didn't even reply to messages of frustrated clients as those kept piling up. Twitter is very fast-paced media; if you stay silent for five minutes, people decide that you're gone (or just don't care) and start asking for status updates. Unless you answer them, they're going to be pissed My opinion is, of course, hugely affected by the fact that 100% of time I'm in some way connected to social media, so if a service provider wants to reach me, that's their best bet (and the number one media I'd check if something was acting up would be Twitter, which is perfect for quick status updates). Not saying that using Twitter would eliminate the need to send important updates as emails, but it can provide very real extra value to a lot of customers. (Also: if my service provider sent me an email each time there's been some little slowdown or a minute of downtime, I'd be equally pissed at them. Each media has it's own merits and email isn't that great for fast-paced messaging. When you're having this scale of an issue it should've been used, though.) On slightly related note, I found that blog post somewhat lacking. Sure, they're saying that things went wrong (+1 for explaining what the issue was), but the rest was mostly just saying that "shit happens" and "we'll try to be better". I'd have expected them to name at least one concrete step they're taking to make sure that this doesn't happen again -- "we're going to learn from this" is abstract and in itself doesn't promise any improvement at all. Communication is a difficult beast to pin down perfectly

@Soma: good point, perhaps that really is the way to go. With id!=2 added, it works just as well (and perhaps even better) anyway. Thanks! I'd still imagine having trouble with this in other places (template=admin and template!=admin are, after all, perfectly valid and usable selectors), but at least for now I'm good

For a module I'm working on I'm trying to use InputfieldSelector to define a selector that iterates pages excluding those with admin template. It seems that InputfieldSelector isn't picking up "template!=admin" (or template=admin for that matter) properly -- does anyone know if a) this is intentional, b) why is that and c) is there a way around this? Currently I'm using "has_parent!=2, id!=2" instead, but that seems potentially unstable (though it's quite unlikely for this ID to change) and much less obvious than "template!=admin". Any ideas?

@davo: thanks, GlusterFS seems interesting. I'll have to dig into that a bit

Nothing wrong with being careful, but luckily we're talking about free software here. If it's any more reassurance, we've got a lot of sites relying on this module already, so trust me: in the (unlikely) scenario that something was to happen and the module wasn't kept up to date, I for one would be more than happy (and forced, actually..) to catch the ball

@davo: yeah, rsync probably would do it, but to keep sites in sync all the time would require this to be triggered after each change to assets etc.. or just to be executed regularly enough to achieve "good enough accuracy" Disabling edit sounds like a good idea to prevent unnecessary mess. Sounds like a good fit for demo mode too.. and just to be really clever, you could even make it dynamic using something like $_SERVER['SERVER_NAME'], so it'll be automagically turned on for the duplicate

Agreed. This might be a valid solution for the user-specificity part, though "regular" bloggers probably shouldn't have the permission to do this -- right? Whether this solves the question of having multiple separate blogs still doesn't seem entirely obvious to me. In another system we've used it was possible to create and embed separate blogs, with their own names and other settings, to different parts of the site. That was pretty handy, actually. Each blog being tied to one user account (in a way that made it impossible to change later) was the problematic part. If only we could somehow had both.. Edit: I'll have to take a closer look at post settings based on @kongondos reply above, but just wanted to clarify the part about "regular bloggers' permissions". In our case bloggers are sometimes actually users that have absolutely no other permissions -- can't edit content etc. Them being able to edit other bloggers' posts or change authors of those would be far from optimal. Could be specific to our case, though..

Sorry for spamming (sort of), but just wanted to comment on this one that most (quite possibly all) of the sites we've implemented a blog for have more than one blog. Doesn't sound that far fetched to me: one or more for internal use, one for each division (a lot of our blogging clients are municipalities and they've got a ton of these), one for CEO/mayor, one for each temporary project etc. Also, if you were referring to creating a bunch of user-specific blogs: I've explained this sort of behaviour (in another system) to clients over and over and over and can assure you that, though it may sound like the logical solution, in real world it just doesn't work.. unless you also allow some sort of "blog superusers" to post with any user account, which could introduce an entire set of new problems One typical situation is a CEO or mayor having his/her own blog. Most people of that caliber simply don't have much spare time and blogging is rarely considered a core task, so even if this person does really write his/her own posts, there's a very high probability that someone else handles posting them online.. which is where the trouble starts if each blog is tied to one user. I'm sure you get the point. Anyway, I'd appreciate if you could consider this kind of feature, but I get that it's probably not too high in priority

Scheduled publishing is an integral part of the workflow for many bloggers, so this would definitely make sense. I couldn't live without such a feature anymore.. @kongondo: if you're still pondering whether to use SchedulePages somehow or cook up your own method, I'd vote for SchedulePages. Admittedly I'm being somewhat selfish here (I'm sure we'll be using this module for our client sites and I don't like the idea of having to explain why and how scheduling posts is different from all other pages) but it's also a great module

There's a setting called "Data max age" in the settings of Changelog Hooks module. That's probably what you were looking for (sorry for taking this long to answer!) If you really need to delete all items, I'd suggest uninstalling and installing the module. That should do the trick. "Delete all" type of button would be simple to add, but I don't really see much benefit in that.. unless it's added to the changelog page (not module settings), but in that case I'd be worried about users accidentally deleting their entire changelog. Unless there's something I'm missing here, I'd probably leave this as is

Out of curiosity, have you done this kind of setup with ProcessWire and if, did you handle files on disk somehow -- assets, perhaps even cache files and session data?

Thanks, Ryan. Let me know how it handles once you do test it, would be interesting to know. My tests so far have been very limited in scope, so I'm fully expecting a pile of issues (and most likely a few things I've completely missed).. though of course the opposite would be cool too You've given me something new to consider there, will definitely take IftRunner and PageAction part into consideration.

Sorry for the delayed answer, Pierre-Luc! Been busy with other stuff and this totally slipped my mind. What you've described there wasn't really possible without direct SQL queries until just a few moments ago. I've just pushed to GitHub an update to VersionControl.module (0.10.0) that adds new $page->versionControlRevisions() method. This isn't properly tested yet, but something like this should work: // current value of field 'headline' echo "Headline for current revision: {$page->headline}<br />"; // value of field 'headline' in previous revision $revisions = array_keys($page->versionControlRevisions(2)); $page->snapshot(null, $revisions[1]); echo "Headline for previous revision: {$page->headline}<br />"; // return Page to it's original (current) state $page->snapshot(); echo "Back to current revision: {$page->headline}<br />"; Since snapshot() returns Page object to given revision or point in time ($page->snapshot($time, $revision)) you'll want to make sure it's back to it's original state in case you're going to make changes and save the page -- otherwise the revision you fetched with snapshot will be returned from history once you save the page. $page->versionControlRevisions() returns an array of revisions for current page and can optionally take one param, $limit, to fetch only that many revisions if more exist. It's return value is in the form of array([revision] => [timestamp]), i.e. array(4 => '2014-01-01 02:00:00', 3 => '2014-01-01 01:00:00') etc. so in order to get just the revision IDs out of that I'm using array_keys() in the example above. You could probably also do something like this, if you want to make sure that Page doesn't get accidentally returned from history (this'll consume more memory, though): $revisions = array_keys($page->versionControlRevisions(2)); $page->previousVersion = clone $page; $page->previousVersion->snapshot(null, $revisions[1]); echo "Headline for previous revision: {$page->previousVersion->headline}<br />"; Not sure if you're still working on this, but this kind of feature felt useful so I'm glad you brought it up..

This is a beta release, so some extra caution is recommended. So far the module has been successfully tested on at least ProcessWire 2.7.2 and 3.0.18, but at least in theory it should work for 2.4/2.5 versions of ProcessWire too. GitHub repo: https://github.com/teppokoivula/ProcessLinkChecker (see README.md for more techy details, settings etc.) What you see is ... This is a module that adds back-end tools for tracking down broken links and unnecessary redirects. That's pretty much all there is to these views right now; I'm still contemplating whether it should also provide a link text section (for SEO purposes etc.) and/or other features. The magic behind the scenes The admin tool (Process module) is about half of Link Checker; the other half is a PHP class called Link Crawler. This is a tool for collecting links from a ProcessWire site, analysing them and storing the outcome to custom database tables. Link Crawler is intended to be triggered via a cron task, but there's also a GUI tool for running the checker. This is a slow process and can result in issues, but for smaller sites and debugging purposes the GUI method works just fine. Just be patient; the data will be there once you wait long enough Now what? For the time being I'd appreciate any comments about the way this is heading and/or whether it's useful to you at all. What would you add to make it more useful for your own use cases? I'm going to continue working on this for sure (it's been a really fun project), but wouldn't mind being pushed to the correct direction early on. This module is already in active use on two relatively big sites I manage. Lately I haven't had any issues with the module, but please consider this a beta release nevertheless; it hasn't been widely tested, and that alone is a reason to avoid calling it "stable" quite yet. Screenshots Dashboard: List of broken links: List of redirects: Check now tool/tab:

@Matthew: no one still seems to have a clear idea, so I guess we can only assume that something big (that they've got no control over) broke down. Network failure or something like that, perhaps? Happens to the best of us, but admittedly they could've explained things in a bit more detail. I was trying to write something here when the downtime started. Kept tabs on it for the first hour or so in hopes it'd be fixed soon, but well..

For your first scenario I can't quite see what the big benefit of session would be, though that depends on the structure of your page and the way you build this thing in the first place. Some possible solutions I'd consider: If the edit view opened in modal box is an external page (not part of this page or put together on the fly) then you'll have to somehow let it know what it is that you want to edit.. and in that case I'd rather provide it with page ID and field ID (or name) as GET params. If the edit view is generated and filled out on the fly (and submitted by AJAX, I'd assume) you can just grab the content from page using JS without the need to store anything in session variables. In your second scenario I'd also consider using GET params (specify comment ID to quote from) or storing either the comment ID or even the whole quoted text (unless you really need to support storing *a lot* of data) in JS cookie. This is an example of situation where you probably don't need to make sure that quoted text is somehow protected (in most cases user can edit it upon posting anyway), so storing that data in session provides very little extra value. -- Considering sessions vs. other methods of storing run-time data in general: Biggest reason I tend to avoid sessions is that as the amount of data stored in session grows in size, so do the memory requirements (and, in extreme cases, also the disk space requirements) of your site. At least some PHP versions load whole session data to memory when session is started, so you can imagine what having tens of kilobytes, hundreds of kilobytes or even megabytes of data (a worst case scenario, but still) does on a site with a lot of simultaneous users. With sessions you'll also want to make sure that you're cleaning stored session files properly (which, by the way, isn't always as trivial as it may sound) and preferably clearing stored values run-time too, especially if you're storing a lot of content. GET params, on the other hand, don't consume any extra memory.. and storing stuff in JS cookies only consumes client resources. As for why one would prefer to use sessions, biggest benefits are that a) session variables make it possible to "hide" the mechanism behind this all from the user and b) session data is much harder (practically impossible, unless you've made it possible yourself) to tamper with (it's easy to try out different values for GET params or alter data stored in JS cookies). Ease of use is a very real benefit too, of course. Storing data in session variables is often the least painful route. Tradeoffs, tradeoffs.. but then again, isn't that what web / software development is always about?

Sounds a bit like "collection" might be a Page type field. If that's the case, try something like $page->collection->title (if it's set to contain one Page) or $page->collection->first()->title (if it's set to contain multiple Pages).

@tobaco: have you tried setting publish_until to current date -- or any other date between now and publish_from? That should do the trick and is, at least in my opinion, preferable to altering existing values (those could be useful for audit purposes etc.)