apeisa

Not sure what it does, but Page object is pretty heavy, cannot keep that many in memory. Probably because all the other stuff instead of just fields. I see this as a little problematic, when trying to use PW in other kind of stuff than websites (ie. building webapps). Especially because PW does have db table per field (and not per template), meaning that building custom queries are not how most of us have used to. Btw: if I print_r($page) on the homepage, the result is a massive. Does it parse every page there or why is that?

Would it be possible to "lazy load" pages? So that it wouldn't load whole page in memory, but just ID:s for example. That would allow PW api to be used in more scenarios (like when you do want to have thousands of items in memory). I guess problem is that to allow those nice selectors we do need to have whole page objects in memory...?

Do you allow one or multiple references? If multiple, then do this: $page->ref_page->first()->title; or then foreach then. If only one is allowed, then set it single page object from field settings and earlier example should work.

Probably not all correct anymore, but basics are true: http://processwire.com/talk/topic/545-progress-on-processwire-22-and-overview-of-multi-language-support/page__st__40__p__5732#entry5732 It should help you get started. If not, feel free to ask help.

This: $page->ref_page; doesn't return the id, it returns the whole page object (echoes the id though, but var_dumb shows the truth). So no need to get(id), because you already have the correct page. This is what you are looking for: $page->ref_page->title; EDIT: And if you do need the id, it can be get with this: $page->ref_page->id;

Jasper - that is probably because it is kind of special case: process module that is also autoload module (because it needs to sniff the 404 visits). I will fix this soon, thanks for letting me know.

Dave - I did notice your pull request regarding discussions module, but I didn't have enough time then to review it. (It's been a while when I have touched the discussions code). Sorry for that. I will concentrate on this module after the summer, since I will need it on a client project. My plans was also include wysiwym.js or something like that with Discussions. So if it is my module that is sanitizing the input, then feel free to modify it. My plans with discussions is to provide nice and simple out of the box functionality, which I think means having some basic styling like what wysiwym offers.

Very clean UI thinking there, I like it.

Nice work Oliver! I think that at least the orientation part should be in core. Quickly looked your module (not tested yet) and I was thinking is there any reason this is an autoload module?

Reasonable and possible for sure, I also like the thinking you have on this. I haven't had the need myself, but surely that would allow more flexible files management. I would probably add small search box there also (on top of the page tree browsing). But I think there are quite a bit work on this and I also think that this is not needed on most sites, so not the first feature on my wishlist. One thing to consider is what removing the original image does for the references? Does those references get deleted too? Or does it copy the image for one reference and that will be the official home then?

Alan, that is pretty much different thing. Here it is not about putting images into TinyMCE (it just saves img tag with right src attribute), but putting images (or files) to image field as a reference.

Just pushed big update on shop module. I don't even remember everything, but here are few details: Shipping options, with additional payment costs (currently only fixed cost shipping option available, but it would be pretty trivial to build more advanced ones also) Uses cookies instead of session - I settled for 7 day cookie ShoppingStepsMarkup.module, which renders 1-5 steps to completed order Bunch of bug fixes (and probably lots of new ones introduced) Most of the fields created are now system fields, so installing this will not pollute your fields & templates. (This doesn't mean you should install this on your favourite live site - don't do that [with any module]) Updated the readme with few (well.. 12 actually) simple steps how to get this baby up and running Get it while it's hot: https://github.com/apeisa/Shop-for-ProcessWire All the feedback and testing is greatly appreciated. Thanks.

Nico: not tested, but probably just adding 'permission' => "page-delete" To your getModuleInfo might do the job.

This is how we use this: www.maindomain.com // This is the mainsite, runs just like any other pw-site www.campaign.com // This is the first one using multisite, this domain is entered into module settings, but also as page under maindomain.com www.anothercampaign.com // Just like the above Admin for all these pages is accessible from www.maindomain.com/processwire/ First level of site tree from maindomain.com looks like this: About Us News Contact us Sitemap www.campaign.com (hidden) www.anothercampaign.com (hidden) I won't suggest building very complicated setups with this, but it is superb for few specific campaign sites (especially if same people maintain or they reuse the data between). If you have many big sites under same site, you will end up with huge amount of templates & fields.

Ryan: I do not know - I have always thought that PCI compliance is more about shops that directly accept or even store credit card information. And not sure what requirements that gives to shopping cart software. After reading more from wikipedia (http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard) I am not much wiser, just that it seems to be more like another way of doing money for cc companies than actually making better security. In Finland there are very few sellers (only the biggest) who store credit card information. Usually we pay directly from our bank account and that payment process is always done in bank's website. And if it is credit card payment it is usually processed on Luottokunta website (they have monopoly like position in Finland afaik, threatened only by paypal and likes). They have quick guide for merchants about PCI compliance: http://www.luottokunta.fi/en/industry/pci_data_security_standard/quick_guide_for_merchants (I didn't come much wiser after reading that either...)

Let's wait for few hours, Ryan releases his page revisions module for PW and let's build the damn wiki, right?

I will implement paypal integration for sure. But that is something that we don't need at our company, so I need to do that on my own time. But I don't think that will take more than few hours at best. I just implemented possibility to add multiple shipping options. Yesterday I build small markup module which renders the shopping steps (1. cart, 2. information, 3. confirmation, 4. payment, 5. order complete). Also some minor tweaks here and there. I will also add option to choose currency (I am not planning to support multiple currencies, but possibility to choose what currency the shop uses will be there). Hopefully I get today all wrapped up and can commit it.

Haha, I knew I had to be fast, this was such a great question. I don't want anyone to believe building modules for PW is hard, it's not.

/site/modules/UserExtension.module <?php class UserExtension extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'User Extension', 'version' => 101, 'summary' => 'Extends $user object.', 'singular' => true, 'autoload' => true, ); } public function init() { $this->addHook('User::sendThankYou', $this, 'sendThankYou'); } public function sendThankYou($event) { $user = $event->data['object']; $event->return = "Thank you, $user->name"; } } Usage is dead simple: <?php echo $user->sendThankYou() ?>

My chrome actually messes favicons if I haven't set one. Shows sometimes one from some other site.

It does contain errors. Just echo $error. Also, can we see the form markup?

Please, do always provide all the error messages and describe "how it doesn't work"?

Possible solutions: a) re-upload everything b) search your files c) look at firebug/other debugging tools to see which files are missing and get the path from there

'1' is string that has text, which contains one number. 1 is integer 1 === 1 (true, because they have same value and type) 1 === "1" (false, because you compare integer to a string) 1 == "1" (true, because == doesn't care about the type)

Setting "View page" to no means they can't access it at all. I am not sure if I understand what you are looking for: you don't want clients see pages in the admin that they cannot edit? I don't think that is possible currently and I found it rather confusing. Our clients love the "bird eye" view that full site tree gives them, it is helpful for them to know where all pages are, regarding if they can edit that page or not. If they don't have access to certain page, then it won't be shown in page tree either. There is permission required for changing template, so just edit the role and disable "Change templates on pages" permission.