Pierre-Luc

Hey guys! I just got a new position in a startup where I'll be in charge of running most things development-related. I did a small presentation to the team on ProcessWire, suffice to say they were very impressed by the ability to run anything from small pages to complex sites/semi-applications, dynamic or static using ProCache. They are currently using mainly WP, but I want to move away from this in the future to cut on dev time/costs and maintenance. I have a few questions, and I hope this will lead to a discussion on best-practices of running a PW shop. I'm used to be a "one man army", so my workflow will need to change.. The questions: Development: ​What have you found to be the best workflows to deploy and version-control PW sites? I'll probably be implementing Docker to help setup things, but what about staging/production using GIT and deployment? Migrations: Since PW doesn't have something like ActiveRecord/Eloquent (yet?), how do you manage migrations? I currently have a workflow that's mainly manual, but that won't scale so well considering we have ~ 40 clients, and plan to have ~ 100 within 2 years. Hiring: Have you found it easy to introduce front- and back-end devs to PW development? I know we'll probably not be finding long-term devs like we can on WP/Joomla/Drupal/Laravel/insert-framework-or-cms-of-choice, so that's something I'm wondering about. Add your own questions! I'm really looking forward for your ideas and feedback. If possible, provide details on your team size and what kind of sites you do most often.

It's such a shame I can only like this once !

cstevensjr, don't worry I was merely playing devil's advocate. I do believe PW is a great solution, even from a user's standpoint, and I think it's adaptable to a great deal of situations! Just gotta keep the user in mind.

Partially disagree. Our top priority is making the user feel as little friction, ever, in their workflow. It doesn't mean they shouldn't adapt sometimes, but still, be extra attentive to their problems. This is an opportunity to learn how to make PW (or your implementations) better. As a community of devs, we need the users to ask for it and love it. I don't want no customer complaining to their contacts how I forced a crappy solution on them — I want them to talk about how awesome their new website is and how the never need to call me cause WP or whatever else is acting up again!

everfreecreative is right. You can also very easily implement a simple router-based MVC architecture with the help of url segments.

Sounds good! I am definitely going forward with the subscription module, so I am indeed interested in having the API as a separate module. I would make it a pretty simple configurable module: public function init() { require_once(__DIR__."/stripe/lib/Stripe.php"); Stripe::setApiKey($this->stripeApiKey); } public static function getModuleConfigInputfields(array $data) { $inputfields = new InputfieldWrapper(); // Option to set the Stripe API Key $fieldApiKey = wire('modules')->get('InputfieldText'); $fieldApiKey->name = 'stripeApiKey'; $fieldApiKey->label = __("API Key"); $fieldApiKey->description = __("Set your live or test secret Stripe key."); if(isset($data['stripeApiKey'])) $fieldApiKey->value = $data['stripeApiKey']; $inputfields->add($fieldApiKey); return $inputfields; } And possibly a default currency as $this->defaultCurrency.

Not only for the API keys but the whole Stripe PHP API. I do think there may be value in decoupling the API from the modules themselves. Any other module (or project) requiring the API wouldn't have to maintain it themselves, which could otherwise lead to problems when loading it twice, or having conflicting versions. Implementing subscriptions is going to be a lot of work, not only do I need to implement subscriptions, I need to add plans (and sync them with Stripe's platform), customer management, payments (and failures), web hooks and a bunch of other stuff like coupons. Right now I'm aiming at making it work within the module itself, but I'm starting to wonder if there wouldn't be value in simply doing a whole Stripe package instead. I really don't have an answer as of yet. I think it's pretty cool to have an agnostic "framework" like you are implementing with support for various payment processors. I wonder though how far this is possible considering the differences in both APIs. I only have much experience with advanced Stripe, so take this as a grain of salt. What's your end goal with this? How far are you thinking of taking it, or do you simply want to have an easy way to make simple payments?

Just a heads up.. I have a prototype working for subscriptions and it's working pretty well. I was thinking maybe we should offer the Stripe API as a separate module dependency, with only Stripe in it. That way I we both could use the Stripe module to load the API keys and not have conflicting Stripe installations.

Sounds good. I already need to be working on this for a few personal projects I want to implement. I'll look at your source more closely and see if I can make similar design decisions to streamline payments workflow on PW. Cheers!

I like it, it's a good start I believe. Personally, I have some pretty basic code to handle all errors in a localized manner (Stripe only). I've been meaning to do something similar, but for the Subscription part of the API. Is that something you'd like to do or do you think it's out of scope? I ask that because subscriptions can be a lot harder to support.. when payment goes through it's all fine, but when cards expire, when people can't simply pay or else, it gets complicated.

@kongondo, it's nice to know. I've been looking for this too myself, but would never have thought to look at the blog for documentation…

The date picker thing was confirmed by Ryan to be a bug, it'll be fixed in the next dev release.

Valid point apeisa, though the BCP47 does already contain this, with the x- extension which is dedicated to private use. I think this would be even more powerful, because it could use the base language as a fall back. For example fr-x-myclient > fr > default/en. That way you wouldn't have to maintain the whole translation strings, just the part you need to specify. I don't know if this would be overkill/technically feasible, but it's an option. Of course free-form could work too, but I would propose like you do that each language be set using a dropdown list of predefined ones (to make support easier), and have a "Custom" entry where an input field would appear to set it as required.

I think it's a good idea too. ProcessWire currently has one of the best multi language support I've seen, but there is room for improvement that I'd like to see too. For example: I've submit a feature request/proposition to support UTF8MB4 in the database by default (would add support for emoticons). There is already some support for this, but by default the SQL loaded to create the basic pages needs to be changed manually. One other thing that might be nice, is instead of letting language name be free-form, we could stick to BCP47 (validator — registry). As an added bonus, we could package language packs for modules or else in a /lang/xx[-xx] format, instead of having to constantly install them manually. It would also make it possible for PW to set setlocale() by itself, without having to add it manually. Default could have a way to set an alias, so that at runtime the language functions would recognize "en" and "default" as the same, for example. This would also be necessary for the second proposition. What are your thoughts on this guys/gals? I think Ryan would probably be glad to receive a patch for this if it's of good enough quality, this could be a community effort. Should we open a new topic to discuss all that?

No problem underk, and I'm glad to provide this translation for all PW users and devs! Also thanks a lot for merging, I don't mind either way if my repo becomes default, or if you add me as a collaborator (repo settings > collaborators) in GitHub so I can commit to it, just a long as we make sure it can easily be kept maintained over the years. Right now the readme.md would need some modification, since the url to Issues points to my repo. In addition, I didn't know the name of all previous translators, so I pretty much just nuked the old readme, but I would have liked to be able to credit previous translators for their work, it was a good starting point.

I've tried it, it does the same for me too when the option for the date/time picker is unset. If you choose one, the date is added. Congrats, I think we've found a bug! A minor one, but I don't think that's the intended behaviour. I'll post a bug report on GitHub for you. EDIT: https://github.com/ryancramerdesign/ProcessWire/issues/882

As I explained earlier, you will need to use a range (min and max values) on created because it uses timestamps to match dates. That would look like created>=2014-01-01, created<2015-01-01. PW doesn't understand only years, you'll need to use properly formatted dates.

You would use url segments on your home page. Then from the segments, build a query using $pages->get("selectors") to return a page from this. You'd probably want to use /2015/01/05/ to select the page by date using the "created" field, and page-title-name to select the page by the "name" field, which is used for urls. It would probably look something like that (note that I didn't test this): $year = $urlSegment1; $month = $urlSegment2; $day = $urlSegment3; $name = $urlSegment4; # Assuming your blog posts use a template called "post"... # You need to do >= and < on created because it's using timestamps, # so you're looking for something in a range $page = $pages->get("template=post, created>={$year}-{$month}-{$day}, created<{$year}-{$month}-{$day+1}, name={$name}"); if(!page) { // redirect to 404 or another page or do something else } . . . I personally wouldn't use a directory structure for this, it just makes moving things harder. In WP, these folders don't really exist really either. Also note that you could probably just skip checking the creation date, since page names (url, not to be confused with the title field) are already unique by default. But you might want it anyway for some reason.

Maybe this is relevant to your problem: https://github.com/ryancramerdesign/ProcessWire/issues/540

I'm having the same issue as Mats. Last tried 15:26 Eastern.

I just edited the initial post. Directories permissions need to be set to 777, for some reason I copied an old version that wasn't working correctly..

I would also greatly suggest you use this to test sending your email : http://www.mail-tester.com. It will also provide suggestions on how to improve your mail delivery systems to prevent outbound emails to be seen as spam.

Just wanted to share a simple bash script I've been using lately to make installing ProcessWire a little faster. Feel free to modify it to your taste! Just copy everything into a simple text file, I call mine "preparepw". Optionally, set this file to executable (chmod -x preparepw) and put it somewhere into your path to be able to load it as a regular command without the need to call it from sh ~/preparepw for example. To run, first cd to where you want to install PW's root, e.g. /sites/mysite/ then call the script. It will create a /sites/mysite/wwwroot/ directory containing all of PW's files from current master, set the required permissions and rename htaccess. It has an option to set the directory that, when unset, will default back to ./wwwroot. (e.g. preparepw public would install PW in ./public/). #!/bin/bash # Version 2.0 INPUT=$1 if [[ -z $INPUT ]]; then INPUT="wwwroot" printf "Directory option not set, installing into ./$INPUT/...\n" else printf "Installing in to ./$INPUT/...\n" fi # Select a version printf "\nWhich ProcessWire branch do you want to install?\n" options=("master" "dev" "devns") select BRANCH in "${options[@]}"; do test -n "$BRANCH" && break; echo ">>> Invalid selection, please try again"; done printf "\nDownloading ProcessWire $BRANCH branch, please hold on...\n" # Get ProcessWire master and prepare files if [ "$BRANCH" == "master" ]; then curl -o processwire.zip https://github.com/ryancramerdesign/ProcessWire/archive/master.zip -# -L fi if [ "$BRANCH" == "dev" ]; then curl -o processwire.zip https://github.com/ryancramerdesign/ProcessWire/archive/dev.zip -# -L fi if [ "$BRANCH" == "devns" ]; then curl -o processwire.zip https://github.com/ryancramerdesign/ProcessWire/archive/devns.zip -# -L fi unzip -q processwire.zip rm processwire.zip if [ "$BRANCH" == "master" ]; then mv ProcessWire-master $INPUT fi if [ "$BRANCH" == "dev" ]; then mv ProcessWire-dev $INPUT fi if [ "$BRANCH" == "devns" ]; then mv ProcessWire-devns $INPUT fi chmod -R u+rwX,go+rX,go-w $INPUT mv $INPUT/htaccess.txt $INPUT/.htaccess cd $INPUT # Prompt for site profile printf "\nWhich site profile will you be using?\n" select d in site-*/; do test -n "$d" && break; echo ">>> Invalid selection, please try again"; done mv $d site/ rm -rf site-*/ # Set permissions chmod 777 site/assets chmod 777 site/modules chmod 666 site/config.php printf "\n" read -p "Press [Enter] once you've finished the installation process to remove the install files..." rm install.php rm -rf site/install printf "\nInstallation files removed.\n" printf "\nDirectory \"$INPUT\" all set for ProcessWire. Have fun! \n"

Please file a bug issue on PW's GitHub page.

Try clearing the cache under Modules > Page Render. Does it change anything?