Leaderboard

Hi Guys, So we have been working with ProcessWire for sometime now. We absolutely love ProcessWire so much that we have changed our site from a custom build on a custom CMS to WordPress and now ProcessWire and will never go back to anything else. We launched a small version of our site to test the migration from WordPress a couple months ago and now have finalized a new look and feel. We are a small team based out of the Chicagoland area that is eager to grow. Our go to CMS is ProcessWire for our clients. Please take a peak at: QuickToImpress.com We are currently running the latest version of ProcessWire with Template Editor Module. We are looking to start building some of our own modules in the near future. Ryan Cramer, thank you for such an incredible CMS. ProcessWire community, thank you for such an amazing group of fellow developers, designers and SEOS. You guys are all great and have helped us grow so much with answers to API questions, suggestions and advice.

Great site.

Thanks for sharing this and great site.

Thanks a lot for the precision apeisa. I subscribed to your mailing list, can't wait to have a go at implementing it (and ditching Shopify!).

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.

Hi Mike, we must have missed this last piece, since that was the last element added to replace a previous message. We simply commented out the previous message temporarily as we have something sweet cooking up to release soon! Thanks for the catch, it is now fixed!

Just wanted to let everyone know that thanks to @Sephiroth we now have support for comment migration - you'll need to grab the latest commits for both Migrator and MigratorWordpress! Next on my list is custom fields ...

here is one more solution, created / based on Somas module

Just for your own sanity break the code into functions where each one is responsible for opening and closing a tag it creates. Pass info to outermost one, it starts a DIV (whatever) and passes info to another function (drilling down in a nested way) then closes the DIV it started. All the opening/closing of the tags works out by itself as the functions return. It's easier to test. Each function handles one level of the nesting and has the tests (logic) and tags (markup) that happen at that level.