Working with Stripe and Terrible Themes

For this project, I had to set up a theme called Ancora Themes CoWorking. At first, the theme wouldn’t work at all in the back-end because it was taking up too many resources. When I tried to change something, it would show a spinner spin indefinitely. Thankfully, I got SSH access to the server and pulled the site down locally.

The client sent a nice sheet of specifications. Those always take a while to understand. Most of the time, I don’t understand very much, but I do what I can. The client typically mentions if I did something wrong.

One spec was adding Stripe to the website. There weren’t really any more instructions than that. At first, I thought it would be a good idea to use WooCommerce, but that was ruled out because you have to buy a plugin for Subscriptions. I’m glad I didn’t use WooCommerce. The Stripe integration was 100% custom. I started by setting up the Stripe library in the theme. But then things started getting out of hand, and I turned it into a plugin. Each pricing block had a button at the bottom that opened a Stripe subscription form in a modal. I used Vex modals for that. Thank you, Vex modals!

I used shortcodes to display the pricing blocks and add each corresponding Stripe form, and I had to create separate forms to keep things nice and clean. I didn’t think it’d be a good idea to use one form for all the modals. I actually started out by using one form and replacing any info, but Stripe complained. It probably wasn’t a good idea anyway. After the PHP created the pricing blocks and Stripe forms, the JavaScript looped through each form and activated Stripe on each one. Very cool. The JavaScript also set up click events to display the forms in Vex modals. We started out with three forms. One was a one-time purchase form, and the other two were subscription forms. I never really understood what the third subscription form was for. They ended up getting rid of it altogether. I used CPT posts to hold data for each form, such as whether it was a subscription or a single purchase. If I would have known that they only needed two forms, I would’ve hardcoded everything. Always. Hardcode. Everything. At. First. There was absolutely no reason for the client to be able to change the info.  The CPT posts weren’t necessary at all, but I’m glad I did it. It might come in handy later. Maybe.

But yeah, I definitely could’ve hard-coded everything and saved a lot of time. There was no reason to dynamically create the forms using shortcode. No reason to dynamically create a CSS ID for the form using the ID of the CPT post. YAGNI! You ain’t gonna need it. That’s a term I learned recently. I guess I was infatuated with trying to make everything DRY. Pshhhh. I did not need to turn it into a plugin. I guess it was helpful, though, because, at the time, there were THREE forms, pricing blocks, and popup modals on TWO different pages. But, now, there’s ONE on ONE page. I guess it made sense at the time.

One tough thing was figuring out how to give a Revolution Slider a video background. It was possible to give each individual slide a video background, but it wasn’t possible for the video to span all three slides. Thankfully, I was able to make the sliders transparent, and I gave the Visual Composer block a video background instead. They ended up getting rid of that too… I replaced it with plain HTML.

The first specs

 

After the initial set up, there were eleven CSS tweaks and other “small” changes from the client. After those, there were 19 other copy changes and CSS tweaks. And after those, there were 28 more changes requested by the client. All the while I was trying to get the slider to work and creating the Stripe form which I wasn’t really sure how would work. I also ended up adding one contact form at the button and one in a popup. I had to do some custom stuff to make it redirect to a page because it was Contact Form 7 form. Oh yeah, then I also added a video in a popup (Popup Maker). Lots of popups on this website. After that there were 37 more changes. All this probably took about 40 hours, and 220 messages were exchanged.

Next came the launch. It was an interesting launch. I had never set up a WordPress site on a AWS before. I had never used AWS either. Also, after launching, I noticed that the back-end was broken for a different reason. There were enough resources, but it was just broken. I found out that it was broken because of some JS that would error out when the theme’s custom shortcode was used in the back-end editor. I didn’t find out what was causing it because the theme was incredibly complicated, but I fixed it later.

Getting the Stripe integration solidified was tough, and most of that happened after I set up the dev site on AWS. I also had to integrate coupons into the Stripe forms. There was so much going on there. I had to grab the user’s data with JS, send it to PHP, restructure and validate it in PHP, and send it to Stripe. Whew!

Then came the SSL issue. A week or two later, we had to move the site over to SSL. We encountered issues. No matter what, it would crash when I changed it over to SSL. I tried everything. Another dev ended up redirecting the site to SSL with JavaScript. Talk about a hack. A useful hack but a hack. I later found out that it was happening because of one little AWS setting. When I would switch it over to SSL, AWS thought it stopped working because a test would fail, and then AWS would cause the 503 error! Thanks, AWS!!! But thankfully, everything turned out okay in the end.