teppo

Good clarifications from both of you This is getting a bit out of hand, but one more addition: in current code image isn't actually resized -- it's just forced to specific dimensions with HTML attributes. This could be intentional, but I'm wondering if this might make even more sense here: ... echo "<img src='{$p->images->first->size($resized_imageWidth, $resized_imageHeight)->url}' width='{$resized_imageWidth}' height='{$resized_imageHeight}'>" . "<a href='{$p->url}'>{$p->title}</a><br />"; ... This way end-user doesn't have to download excessively large images, if what you really want here is a thumb. It should also be noted that simply defining width and height with HTML attributes forces image to those exact dimensions without considering actual aspect ratio, which can easily result in distorted images. (More about various options that size() accepts here.)

Another clarification. (I seem to need these a lot these days.) As is (probably) made quite obvious by the SQL statements above, get() with a Page ID doesn't care about the status of the page at all. It returns hidden and unpublished pages too, making it somewhat equal to find() with "include=all". This is important to keep in mind in case that those pages you're "getting" could've been unpublished in the meantime; if that's possible, you really should add another check for $p->viewable() before displaying content. With this addition, nfil's final code could look like this: $resized_imageWidth = 120; $resized_imageHeight = 0; $session->history = is_array($session->history) ? array_slice(array_merge(array($page->id), $session->history), 0, 4) : array($page->id); foreach ($session->history as $page_id) { $p = $pages->get($page_id); if (!$p->viewable() || $p->template != "basic-page") continue; echo "<img src='{$p->images->first->url}' width='{$resized_imageWidth}' height='{$resized_imageHeight}'>" . "<a href='{$p->url}'>{$p->title}</a><br />"; }

Very good clarification. My explanation earlier was way too vague What I meant was that you can't find from a single page, i.e. use find like a filter for one page. You can find from children of given page, though: $pages->get(123)->find("template=basic-page") would return children of page 123 with template "basic-page" recursively, while $pages->get(123)->children("template=basic-page") would only return matching direct children. That's another way to do it. With find() you could also do something like this to, perhaps, simplify it a bit: $p = $pages->find("id=$page_id, template=basic-page")->first(); if (!$p) continue; echo .... Quick look at the SQL generated by get() vs. find(): SELECT id, templates_id FROM pages WHERE id=1001 SELECT pages.id,pages.parent_id,pages.templates_id FROM `pages` WHERE (pages.id=1001) AND (pages.templates_id=29) AND (pages.status<1024) GROUP BY pages.id /* Selector id=1001, template=basic-page, status<1024 */ I would assume first one (get) to be slightly faster, but this is micro-optimisation at it's best and doesn't usually matter at all in real world use. I prefer get() for getting single pages as it's the straightforward way

We've used Balsamiq for couple of years now and generally speaking I'm very happy with it as long as static wireframes go. Compared to other tools we used before (FlairBuilder and Photoshop mainly) it's been a huge improvement: type a few characters to find correct element (there's a menu for mouse addicts too), throw it to your canvas and drag to arrange while Balsamiq takes care of alignments etc. It has saved me countless hours of boring, repetitive work. One noteworthy downside with some other mockup tools was that they made things look too clean. Clients took one look and started commenting on colors, backgrounds, content etc. Lesson learned; mockups *should* look scruffy. This is probably pretty standard feature nowadays, though. Lately I've been transitioning to HTML wireframes, mostly for the reasons Reno mentioned already. Static mockups fail badly when it comes to visualizing how responsive site behaves on different situations.. and with PW I can actually make them fully functional while I'm at it, giving the client even better understanding about how the site is going to behave once finished

I'm glad I could help.. and this actually looks quite interesting, might have use for similar snippet somewhere

@nfil: $pages->get($page_id) returns one page and you can't "find" from one page Try adding new row after $p = $pages->get($pages_id) with something like this: if ($p->template != "basic-page") continue;

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