teppo

You might want to try what Ryan suggests here: http://processwire.com/talk/topic/1142-lots-of-sessions/?p=30237. Session garbage cleaning isn't currently working on certain systems with default config (more about that here). Garbage cleaning for sessions is always random and it's possible that it just hasn't happened for a while. Hard to say without knowing a bit more about your environment, how often new sessions are created etc. Anyway, above solution shouldn't cause any harm either, so I'd try if it helps.

Makes sense I usually do that with Chrome dev tools. It's not that pretty, but handles the job of collapsing, displaying data types and lengths etc. quite well.

Still somewhat ugly, but I'd probably go with something like this: $session->history = is_array($session->history) ? array_slice(array_merge(array($page->id), $session->history), 0, 4) : array($page->id); After that you can output stored data like this: foreach ($session->history as $page_id) { $p = $pages->get($page_id); echo "<a href='{$p->url}'>{$p->title}</a><br />"; }

.. and then there's var_dump(json_decode($json)). Seriously speaking, though, the quality of these tools is amazing. I'm having hard time imagining where I would use any of those, but they're all totally cool nevertheless

@homma: sorry, that was another 2.4 dependency. It should be fixed now (just pushed updated version 1.3.5 to GitHub). Had to change one $modules->getInstall() call to $modules->get(). No idea why I decided to use that in the first place, so this could have unwanted side-effects, but everything seems to work fine so far.

Whether it's drinking beer (nothing wrong with that, by the way) or something else, just keep us posted.

Process Export Profile creates /site/install/ directory, which contains database export (including contents of your modules table) and assets. When installing new site from a site profile, download ProcessWire, copy aforementioned /site/install/ directory over existing /site/install/ in the fresh ProcessWire copy and then run installer. It's that simple, really. Note that you'll also have to manually copy /site/modules/ and /site/templates/ from your "base site" to new site in order to include those in your new installation.

Good guess from Pete Most Linux distributions provide certain level of support for packages, such as PHP, included in their (still supported) releases. They won't upgrade PHP as a whole, but they'll backport security fixes. PHP 5.3.3-7+squeeze19 is simply PHP version shipped with Debian release "squeeze" and contains, most likely, various security enhancements over "vanilla" PHP 5.3.3. By the way, regarding required PHP version there's another thread you might want to take a look at too.

At the moment there's no (native) way to do this. Related discussions you might want to take a look at: http://processwire.com/talk/topic/2437-possibility-to-set-limit-of-repeater-items/ http://processwire.com/talk/topic/1465-repeater-repeatermaxitems-gone/ This feature actually already exists in repeater code, but it's not in use and I've no idea at what state it really is. I'm guessing that Ryan would've enabled it already if it was 100% solid and working, though

Have you already checked out Process Export Profile? It automates most of the tasks required here. You'll still have to copy existing /site/modules/ path etc. but the module does provide proper instructions for all that too. Another option is simply copying your current site, changing just the bits in /site/config.php you need changed. That's what I usually do -- create a solid "base site" and then just duplicate it when needed. Depends on your needs, really. Edit: recent and somewhat related topic: http://processwire.com/talk/topic/5736-export-profile/.

Looks like I had accidentally introduced dependency to PW 2.4.0 with one of my earlier commits. Version 1.3.4, just pushed to GitHub, fixes this.. and again, thanks for reporting this, @homma!

Thanks, @adrianromega -- based on your description this was easy to track down, though I ended up trying couple of different fixes. Current version (1.3.3) fires inject() method only for GET requests, which seems to fix this issue for me. Just for the record, another option was not to trigger it for AJAX requests, but I'm assuming that request method is safer bet here.

Just stepping in to say that it's a real shame how complicated things have gone for you, @tiptronic. That's absolutely not how things usually go with PW, you just jumped in at somewhat bad time. Quite a few changes going on I've just reported the problem you mentioned (installing existing Admin Themes via Modules) as an issue at GitHub. Like Soma mentioned earlier, I'm sure Ryan will handle that. Slightly off-topic, but the way Modules section handles non-compatible modules was a bit of a surprise to me too. This was actually the first time I used that thing and I entirely missed the note about Teflon not "necessarily" being 2.4 compatible. Bad combination -- small and unnoticeable message at the bottom of the screen and a hasty user. Personally I would've been happy with Modules section not allowing installing non-compatible modules at all (you can always do that manually, making it this easy is IMHO not such a good idea), but putting that aside, the error message is awfully unobtrusive. How 'bout (at least) adding a big notice at the top of the screen, warning that you're doing this on your own risk? Edit: ended up opening another issue for this..

@horst: thanks for your input.. and your rare case is actually quite familiar for me, so I definitely get that Fallback I mentioned earlier was actually intended as sort of an "installation helper", so that if you install the module on a server where PHP's mail() works (but you just don't want to use it or would prefer to use something else), it won't break anything. Running start, kind of. Thinking about it now, a better solution for that might be setting the module to use Mail by default.. after that I could safely assume that if SMTP is selected but misconfigured, it's user error and exception should be thrown. This module can, after all, be used for Mail and Sendmail too, even though SMTP seems generally speaking most useful option and Mail definitely the least useful one.. Will have to give this some more thought, though. So far none of the options available seems to be clearly the best way to go. In any case you're definitely right in that it's not always possible (or even sensible for that matter) to attempt correcting mistakes user might've made.

@MikeB: no worries, this is just about as good as any other place to ask questions Great timing here, too. Just today I wrote in another thread that integers (such as 32 for version 0.3.2 or 132 for version 1.3.2) feel wrong to me because they can only handle a subset of version numbers. Integers are the default you'll see used a lot, but you can (and, when it's useful, should) use strings like '1.3.12' instead. It should work everywhere just as well as integers (and if it doesn't, that's most likely a bug).

@adrianromega and @homma: thanks for reporting these issues. I've been terribly busy lately, but will take the time to process these properly (hopefully) this weekend. Your posts are noted and much appreciated

Issue was quite obvious, actually: that "if" made sure that Swift Mailer wouldn't get initiated with SMTP transport unless it was properly configured. With the old logic this would've been fine, but not anymore, since local send() method is called regardless of whether Swift Mailer is available. Stupid mistake from me I've changed this so that if you select SMTP transport but don't fill in required params (server and port), the module will fallback to Mail. This (kind of) brings up another possible issue, though I'm not exactly sure how to deal with that yet: what to do when there's a connection issue in send()? Should that be caught and logged, should I throw an exception.. or is there even better alternative? So far I'm thinking that an exception would be best way to handle this, so that apps / sites that rely on mail getting won't just continue like nothing happened.. though that might actually cause even more confusion. Suggestions would be more than welcome

@ryan: thanks, great suggestions! I did notice the issue with saving settings, but had planned to reduce it to a proper test case and submit as an issue. Should've acted faster and disabled it right away, though, to avoid any unnecessary confusion Autoload and singular state were carried over from the original module, the intention of which was quite different from current implementation. I've taken care of these already, but will have to change the require logic you mentioned, as that admittedly no longer makes sense (and path part would've made sense even in the original form). So far I haven't been able to reproduce this. Will continue testing, though, since if it happened to you it's probably going to happen to others too. Shouldn't be too hard to figure out (*fingers crossed*). I remember having problems remembering and "getting" the version number logic originally -- 006 was probably carried over from the time I first put this module together. Lately I've used integers, as that seems to be the expected thing there. Slightly off-topic, perhaps, but integers still seem like a bad fit for version numbers to me. Version numbers should be able to go beyond 0-9 range.. and how do you represent versions such as 1.11.24 as an integer without actually using three sets of numbers? Of course there's always the option of using strings in those cases, but I find it weird that integers are seen as "the default way" while they are only capable of representing some version numbers properly

Sounds like a good way to deal with it. That way users trying to get an ID that doesn't exist would simply get your default home page. Makes sense.

Quick tip: you can also use $pages->count($yourSelector) to get the number of matching pages. That's just a shorthand though, under the hood it does exactly what @horst did earlier

PHP doesn't like Exceptions in included files and (assuming that it's prependTemplateFile) _init.php is included during page rendering. I'd suggest putting together a simple module for this. Edit: you could, probably, also do this in your home template, right? Assuming that old URL's were always "/?id=*", they should always end up on your home page and that should work just as well.. or even better?

If the error is "request header or cookie too large", it'd be helpful if you could take a look at headers and cookies sent for that request and see if there are any anomalies there. From there it would be easier to debug why that's happening