apeisa

Peter, have you tried the latest dev? Adrian and Ryan might have baked something for you

Thanks, updated! https://github.com/apeisa/InputfieldFlickr/commit/66de0f2efbea3574b9836aec8e27449c0b0e9bfa This is fun module, pretty rough on the edges, but I did found this super useful in certain projects (also in quick prototyping).

Marcus & Owzim, great project - looking forward for contributing every now and then (just created one pull request)!

This works great with Template cache, but not with ProCache (which completely bypasses php). JS solution works with ProCache also.

Hi Alex and thanks for your interest. Actually in my first PadLoper version (from summer), nothing was page. But the development speed, extensibility, familiar API etc makes the Pages way almost always a better choice and I have to say I am super happy with my decision to change into pages. Not sure I understand why eCommerce is any harder or easier than any other kind of website in case of continuous integration? It's not easy to do with ProcessWire (or any system with flexible meta model and with systems that keep metadata and actual data both in same database). But in my opinion to really see big issue here (with using pages as orders) is that in your code you would need to reference your pages/templates/fields with ID, and I don't see that need very easily. Although I might be completely wrong though and I am happy to hear more about your process of maintaining local, staging and production server with ProcessWire sites and why you believe eCommerce makes it harder? Like with almost every other big theme, PadLoper tries to stay as close as ProcessWire way of doing things instead of inventing it's own. It tries to be as invisible as possible with your current ProcessWire workflow. It doesn't generate any markup (you can use it's helpers though), it uses templates/pages for data storage and process modules for admin views. It has few custom tables (for cart and downloads).

Pierre-Luc: on the product catalog side: everything you have in your PW arsenal, will be in your PadLoper shop also. So multi-language. image galleries etc.. all that kind of things will be done how you like to do them with ProcessWire. So multi-language products are definitely easy thing. Your idea about multilang emails is interesting - and I have it already covered. I actually don't store any templates in text files (I dislike any templates in text areas). What I have setup is very simple (but may I say clever!) thing. All the default templates are stored in /site/modules/PadLoper/templates/*.*. Those are normal PW template files. so you have all the template variables and multilang stuff available there. But I don't want anyone to edit those files directly, so you can add same templates into /site/templates/padloper/*.* and PadLoper will use those instead. So let's say we have email-order-confirmation.php template file. It's by default multilang ready, but if you want to customize it further, you simple copy the file into /site/templates/padloper/email-order-confirmation.php and edit it to your needs. And remember, you have all the template variables available, like $pages, $modules, $config etc.. Many of the templates also get $order variable, which has the current order and all it's information (customer, products, prices, taxes etc). If you want to use these templates in your own code, it's also simple: $t = $modules->get("PadRender")->getPadTemplate("email-order-confirmation.php"); $t->set("order", $order); // This template file requires $order variable echo $t->render(); That make's it sure that you always get the customized version, if you have one, and the default one for those that don't have. And then of course I have shortcuts for the most common templates, renderCart() etc - but customizing their markup is as simple as others (just creating copy of the file into site/templates/padloper/ folder.

Mike, my humble opinion, that you have already huge amount of features. Adding more makes starting to use this module in simpler cases more difficult: "I installed it and it felt like total overkill for my needs.". Of course we have the current redirects module for those needs... But I think your feature set is great and would much rather see the current as stable instead of more scenarios supported.

Better solution might be editing the field and have it return single page instead of PageArray - and then remove the first().

Hi Jay and thanks for the interest. What you are describing is not something I would recommend doing by using PadLoper product variations. In PadLoper each variation requires page id, so you can build variations using pages, repeaters or PageTable. That allows each product variation have their own unique price and stock. What you are after are more like perks or modifiers. Like additional services or modifications on product - which either increase or decrease the price and they don't have stock of their own. I have been thinking about that concept and will add those at some point, but you won't find them from first release. Although I am planning good hooks to make it possible to add things like that pretty easily with little custom coding per site.

$item->price_currency returns page id like it should. $item->price_currency->title should give you what you are after. If these don't work, then make sure you have single page reference for the field price_currency. If this $item->price_currency->first()->title works, then your field returns multiple pages (PageArray).

I have seen few blinks too - usually when doing something with modules if I reckon right. It has always been just for one page load and having some debug information like in Mike's screenshot.

The error is on js/markup side, so there must be something interfering with that. Nastiest ones I have had was Google pagespeed Apache module breaking my javascript (not related to PW though).

Never seen bug like that on screenshot. Any autoload modules installed? Do you see it always and also on fresh install? Any browser plugins installed?

Hard refresh, sorry. Basically F5 few times to make sure no local cache of css or js.

Which version? Any autoload modules? Hard reloads after removing modules / custom js?

I just send first newsletter out with some badly cropped screens: http://eepurl.com/bagVe9

Wanze, just wanted to say thanks for this module - worked without any flaws. Very easy to setup!

Interesting! Thanks for your patience. Can you post an issue to GitHub with that information?

Module doesn't do anything with file permissions either. Uses a lot's of hooks though - so if your server setup doesn't work with this, there might be problems with other modules too.

Nope, nothing to do with htaccess. My only guess (based on the error message) is that some autoload file is only partly transferred. 2.5.10 is more than required, works great in 2.4 also, if I remember correctly.

No idea about that error - Teppo? Are you sure you have all files fully transferred?

Teppo, most of the big players (others than Google and Apple) are not ready yet. Etsy, gumroad, you name it. This whole thing got everyone by surprise. I actually called to tax office here in Finland two months ago about PadLoper sales. The answer was, that as long as I sell under 8000€ a year, no need to pay taxes - it's enough to just tell about this income (and that way I pay huge side income tax). But my point is that even tax office didn't know about this 2 months ago. The thing I'm most interested is how on earth EU believes they can even in theory collect taxes from single person from India who sells pdf book online? For me it seems that micro businesses were just not considered while making these rules and there will be sooner or later new guidelines coming.

There are cases where required logging in is beneficial. But I think that most often the simplicity of "click a link and download" is what one expects. This also leaves all the stress of creating and managing user accounts etc. Orders are tied into user accounts, if buyer is logged in while creating the order. So one can create that kind of functionality if required. PadLoper won't offer it out of the box though.

The name comes from the little turtle, like Teppo mentioned. No specific reason for that name. As a father of two (soon three) kids, I know that everyone needs a name - those are pretty handy. PS: pad is also handy prefix, there will be padcart, padorders etc...