teppo

I'm not saying that this is a bad idea, but it won't fit all needs -- and thus it might not make sense to complicate the built-in login system with it. When it comes to login systems, "friendlier" could also be considered "less secure" -- but that isn't really such a huge issue here, brute force attacks being already pretty unlikely with Session Login Throttle enabled by default etc. Anyway, you can always roll your own custom login if you prefer something more specific: see this post by Ryan for an example.

First of all, I'm a big fan of PW's current admin UI and also aware of other possible admin themes, but I'm also very happy about the discussion in that thread @kongondo linked above.. and thus also the opinions expressed here Common argument here and elsewhere seems to be that PW allows you to swap the default admin theme to something else, but I don't think that people saying this are really getting it. There's a very special position deserved for default theme. It's an entry point, first impressions are based on it, and it also plays an important role when defining PW's external image, ie. what kind of message it wants to send. I've evaluated a few CMS products myself and I must admit that for me first impressions are very important. I'm the kind of guy who first looks for screenshots and then reads the specs. That's just how my mind works and saying that it's "wrong" is, in my humble opinion, more than a bit arrogant. Current default admin theme is very usable and I myself like it's simplicity a lot, but that two-column layout @Philipp presented in aforementioned thread was simply jaw-dropping. Just because PW is a flexible framework for building awesome custom stuff doesn't mean that it can't be pretty and sexy out-of-the-box, especially if that's what many (otherwise very capable) web designers / developers are looking for. There are a lot of CMS products around that all claim to be flexible, extensible and usable. It's simply not an easy market to crack and thus I don't think that we should skip over any steps that can make PW's road less rocky.

Ryan has explained reasoning behind this here (and on couple of other posts, actually, that just came up first.) In addition to what @apeisa suggested above, you could probably use Pete's Maintenance Mode module to achieve what you're asking (not tested, but based on module description it should be doable.)

Hello Joe -- welcome to the forum! Can't really say right away what could cause this, but that sounds like image resizing gone wrong. Are you using master or dev branch of ProcessWire and is there anything strange either at the server error log or PW's own error log at /site/assets/logs/errors.txt? There have been some changes to image handling in dev branch lately, but I haven't really been keeping track of those, so if you're using dev you could always try installing new PW from master branch to see if the issue exists there too. Also, are there any other files in that directory, apart from x.jpg and cabin1.x.jpg (are these actual filenames by the way?) It would also be helpful if you posted some basic details about your server.. is it running Linux, OS X or Windows, is the web server Apache, ngingx or something else etc.

There's a "record" button for this at the bottom of Network panel, labeled "Preserve Log upon Navigation." Anyway, I definitely get what you're saying -- it's pretty much the same for me whenever I try to use Firebug these days. Most of the time both tools seem to do similar things, they're just organized differently. If you're a hardcore JS developer Chrome dev tools has stronger toolbox for you, but otherwise it won't really matter that much @Soma: agreed, speed was definitely a big factor for me when switching to Chrome in the first place. Generally speaking it just seems to function much faster and it's UI is super simple and uncluttered. Can't say anything about FF dev tools, except that the 3D view is absolutely hilarious.. useless (at least from my point of view) but very fun. Looks like FF devs are focusing on some very important stuff there

Is this a question of preference or does Firebug still do something that Chrome dev tools don't and/or do something way better? Asking mostly out of sheer curiosity, as I've dumped FF+Firebug long time ago myself

There have been a few rumors flying around about Elop's actions and motives as the CEO of Nokia, but who knows.. there's no solid proof about anything like that, of course. In any case both the fall of Nokia and the fact that they've already embraced Windows could be seen as fortunate things for MS, who seem to be looking for an easy way to grab their slice of the mobile market Oh, and by the way: MS is only buying mobile phone unit of Nokia. That's just one part of Nokia, although admittedly best known (especially in consumer market.) In a way this could actually be a good move for Nokia, as the mobile market clearly hasn't been working too well for them lately.

@ryan, any progress on this issue? Just checking, 'cause we're getting reports of this one from clients. I might take a closer look at this one soon, but wouldn't want to repeat steps you might've already taken..

See http://processwire.com/talk/topic/2376-funky-session-behaviour-in-module/?p=22396. Haven't tried this with PW and can't say for sure, though, but it looks like a good start

This is intentional behavior. Personally I'd prefer to have this as a config setting somewhere, though, just to cover those (admittedly very rare) cases where huge pager makes sense.

RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC] RewriteRule ^(.*)$ http://%1/$1 [R=301,L] Just for the record, you might want to consider the benefits of using www-subdomain before doing this, though.

Whether repeater or not, this sounds just like the solution we've been missing. I'm always worried about giving editors too much freedom, as I've seen how that often leads into bloated sites with very little structure (and eventually it's all so messed up that starting over from scratch is only solution), but by maintaining the control of what can be inserted and where this sounds like a very good compromise between giving the user enough freedom while still not letting her create a mess. Just for the record: I'm not too interested in small "campaign style" sites consisting of couple of pages, where any kind of mess is still controllable. Sites I'm worried about are those with hundreds, thousands, or even tens of thousands of pages. That's when things can very easily get out of control unless proper constraints are in place. PS. Reading that post made me spill coffee all over my laptop. Not sure if that's a sign of me being totally excited about this or simply a reminder to avoid any and all activities requiring hand-eye coordination before actually having that first cup of morning coffee.

@ryan: I'm afraid that's quite an overstatement, but thank you very much

Thanks, guys -- and thanks for the heads-up, looks like cache was preventing non-logged-in users from posting comments! Mysteriously some comments still got through, must've had perfect timing there (freshly expired cache)

Exactly what I was referring to above as instantiating MyAwesomeModule in the included file Taking another look at this situation: in case that you need any class variables of the original MyAwesomeModule instance, you'd probably be better off sending it ($this) to your included function as a param as explained in my previous reply.. and you might even want to send the $event object as another param, in case that you need to do something there that's related to the page you're saving: // in MyAwesomeModule: functionFromIncludedFile($this, $event); // and then in that function in your include file: function functionFromIncludedFile($awesome, $event) { $awesome->bla1(); $page = $event->arguments[0]; // etc. } This still sounds like something you could do without dependencies going all over the place (first class depending on second class depending on methods / variables of first class..) but I won't go there as I still don't know nearly enough of your needs