apeisa

For that purpose you could use $pages->find("sort=-modified, limit=5"). But I do think that would be nice addition or a great separate module.

Template caching is set from setup => templates => template name => cache

It's not about quality or likes of the posts, it just about the quantity!

Now it actually happened. There are too many unread topics to read them all! This must be biggest leap in forum activity since 1997 when Soma joined. And it's a pretty amazing and great news!

You should use markupCache module instead and cache only parts of your output. So your code might be something like that: <?php $cache = $modules->get("MarkupCache"); switch($session->typeOfVisitor) { case "lucky": if(!$data = $cache->get("lucky")) { $data = "You are lucky"; // Here you would actually get the real output... $data->save($data); } echo $data; break; case "unlucky": if(!$data = $cache->get("unlucky")) { $data = "You are unlucky"; // Here you would actually get the real output... $data->save($data); } echo $data; break; }

That kind of setting (dynamic content) will not work with template cache. It caches the whole page output and outputs that for all guest visitors.

I try to reuse the fields as much as possible. But don't reuse fields if that doesn't make sense on code level. General ones usually work just fine, like title, summary and body: <h1><?= $post->title ?></h1> <p><?= $post->summary ?></p> <?php foreach ($post->tags as $tag) { echo "<em>$tag->title</em>"; } // I would say that is much cleaner than having $post->post_body etc... ?> But don't start doing this kind of things, even if the field would fit in other aspects: echo $tag->author; // "author" here means tag description...

In Finland most people pay with their online bank, each of them have little bit different payments gateways so it usually took something like 4-8 different gateways for each online shop. And that was the easy and cheap part: merchant also needed to open account on each banks and create agreements for online payments with each bank. Paypal is not that popular and neither is credit cards. But, few years ago payment integrators started popping and it has been much nicer to implement these. One agreement, all the banks + credit cards and more exotic payment methods. This is what most seem to use nowadays here in Finland: http://suomenverkkomaksut.fi/ (their name means something like: "Webpayments Finland") and it is the only payment method I have implemented for the shop so far: https://github.com/apeisa/PaymentSuomenVerkkomaksut I have also implemented PaymentExample to show how to create payment methods in PW shop: https://github.com/apeisa/Shop-for-ProcessWire/blob/master/PaymentExample.module and this most simplest "invoice" payment method: https://github.com/apeisa/Shop-for-ProcessWire/blob/master/PaymentInvoice.module Those are good ones to take a look if you are planning to implement payment methods.

Interesting question - it is kind of reverse page field or something like that. Lot's of directions how this could be handled and I think we need to think about it carefully. This is pretty rare reference, but I see the huge value in this particular case.

usually integrations are super simple, few hours each.

Development of shop module hasn't stopped. It has been running on live site for that 8 months. I just recently implemented product variations, but need to think about those a little more. Since we have implemented only one shop with pw, we haven't had that many feature requests. But I am happy to collaboration and we will definitely push shop module further when some of our clients need it. And zero problems in that 8 months, I might add.

I think what soma is suggesting is good for single site, but not good in general, if all modules need to do that kind of stuff. I don't like that module titles get translated and best solution here would be to have little tweak on core for processlist.

Reno, it sure is.

Another example.. build from ProcessHello and really fresh: https://gist.github.com/4289451

It is possible, but you need to set sessions for domain.com, not www.domain.com or m.domain.com etc. Not sure if that is possible with $session though, but you can always use $_SESSION superglobal. More to read: http://www.epigroove.com/posts/87/using_php_sessions_across_subdomains https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/Session.php

Steve, I took another look at this module, since I might have upcoming requirement to have admin emailed every time any page is saved. This module is pretty close hit, but does much more and in more granular way (fields instead of pages and specific changes). This will be great reference for me if I end up building something similar but for pages. But while I was looking through code I noticed that there is sql-query as a first thing in init() method. Is there really need to have that sql in each page load, or could it be done later?

Great stuff Joss. I just quickly looked at it - only thing that I noticed is that you mention word "content type" at few places - I think those should be templates instead.

I just recently discovered the height: auto; trick myself, and yes, it does solve the problem very nicely.

Well, that is the default behavior: sanitize and let it be. It was just recently when we got the "required" which is only thing that throws inline error on top of the field. Maybe search the source how it does it? (I don't know myself, haven't taken a look yet) The few times I have done something similar I have hooked into page save and throwing just general error message: $this->error("You have too many characters in your body-field, some cropping occured"); This might be for a little help: https://github.com/formmailer/SchedulePages/blob/master/SchedulePages.module#L102

Template Decorator is for dev branch only, that is the reason why Mindplay hasn't added it into modules directory yet.

I think so too.

What does JS console say? PW error logs? Apache error logs?

That is a brilliant idea! I think that and full featured "build your first website" -tutorial should be main focus on documentation side at the moment.

Usually I use: $page->viewable() It is little different, since it does access checking etc. I think there isn't isPublished() by historical reasons - we didn't have "published/unpublished" status at some point. Hidden is different from published: hidden pages can be viewable, but by default they are excluded from find(), children() etc selectors.

Adam, in modules you need to use $this->_()