[PayPal] 22 Reasons You Can’t Rush The Push

This week saw two more videos added to the Symfony 4 Beginners Tutorial series. There’s only one more video left in this series, which I am going to record over the weekend.

I also will be recording a further ~10 videos on deploying Symfony 4 using a variety of methods. How far I’ll get with these is uncertain at the moment.

As a little bit of insight into my video tutorial creation process:

Each video takes me about three times longer to record than the final length of video would suggest. By which I mean if a video is 5 minutes long, it takes me ~15 minutes to record. The editing takes me anywhere from 2 to 10 minutes per minute of video.

That means for 15 minutes of raw footage I would spend about an hour on the edit. I’d love to make more videos but hopefully that explains why they take a while to release.

My favourite video from this week’s set is this one on AbstractController. I’d love to hear your feedback on it.

Support Changes

I’d like to welcome Joel to the CodeReviewVideos team.

Joel will be handling support issues. As a heads up, Joel is not a Symfony / software developer.

Can I please ask that any technical questions related to video content be left as a comment on the relevant video.

I am working to replace the comments section with an alternative to Disqus. I like the service Disqus offer, but appreciate that having to sign in to two services is not good. A better alternative is coming, but for now, please use the comments system.

PayPal Integration

I mentioned last week that I’m adding PayPal (via Braintree) as a payment method.

I get asked frequently how this is coming along. The answer is: as well as I can expect 🙂

I was a little over optimistic with my due date estimate.

Payment integration is a ton of work. There’s a bunch of obvious tasks:

  • Does the sign up form work with PayPal?
  • Is the payment processed?
  • Is the subscription activated?

And so on.

Then there’s the big list of “oh yeah, I forgot about that” stuff. Things like:

  • Invoices
  • Updating card details for an active subscription
  • “Translating” the errors returned for failed payments into stuff humans understand
  • Not allowing an upgrade from payment Plan A to Plan A
  • Showing the correct proration amount on a payment upgrade

And the like. Some of these issues are small, others are bigger.

During my research into this I found out about services like Chargebee – a one stop shop for this kind of thing. Or in Laravel-land, there is Spark. And in Rails, bullet train.

I was curious as to whether others in Symfony-land would find this kind of thing useful?

The response was sadly underwhelming. I mean I know I have a small number of followers on Twitter, but surely this could be useful to more than just me? Especially given that the other services I mentioned above are $$$.

Wrapping Up

Thanks to everyone who replied to last weeks email. There were a small number interested in seeing videos on PayPal / Stripe integration with Symfony. I’ve added the idea to my list and prioritised according to that feedback.

I’m looking forwards to having finished this PayPal work as I’m itching to get back to writing and recording new content. I have a bunch of topics to cover.

Until next time, have a great weekend and happy coding.


Symfony 4: Removing the Mystery

The Beginners Symfony 4 tutorial is in progress. I have all but the final video recorded now. I ended up re-recording a number of sections in both of the recent video uploads:


One of the areas I found most confusing when first starting with Symfony was in the widespread use of Interfaces.

You may have encountered the following problem:

Let’s say you’re working under a tight deadline. You’re writing some Symfony Controller code and working with a form. It’s not going quite as smoothly as you’d like. You reckon something is going awry with the form submission.

Being the inquisitive developer, you remember the oft touted advice:

Read the source, Luke

The thing is, when you ctrl+click on $form->submit($request); you’re taken to… an interface.

This is good stuff.

Your life will be much easier if you code to an interface, rather than tie your methods to specific implementations.

However, with that deadline looming over your shoulder, such things are nice to know, but right now, just show me the code!

Finding An Implementation

When I first recorded this video I initially just said what the outcome of a call to the submit  method would be.

Watching back, I couldn’t help but think about that stuck, and stressed developer. Sat in a noisy office, headphones in, listening to music when you’d rather have peace and quiet.

Everyone around you seems to be goofing off whilst you’re struggling to think through this really important problem.

The last thing you need is to be met with this weird interface  thing. If only you could find the implementation then life would be a lot less stressful.

How can you find out what is really happening when you call $form->submit($request);?

And what happens when you find the implementation and even then the code is tricky to follow?

I know these feels.

That’s why when recording this video I worked hard to make sure you come out at the end with a good understanding of the code that makes this happen.

This is a beginners series for Symfony 4. This is the stuff that will make working with, and understanding Symfony that much easier.

I hope you enjoy it.

Site Stuff

There’s a ton of work going on behind the scenes at the moment.

Can I pay by PayPal?

This is one of the most frequently asked questions that I get.

Currently: no.

That sucks. I appreciate that.

The reasoning for this is that Stripe is super shiny and as a developer, they were high on my wish list of cool things to implement.

Also, from a code perspective Stripe is actually a joy to work with. They really are awesome.

But still, I get asked a lot for PayPal.

I’m adding PayPal.

It’s quite a big job, but I’m about 65% of the way through the implementation.

Here’s a sneak peak:

That’s the Stripe form using Stripe’s React elements.

PayPal functionality is provided through Braintree.

There’s a nice transition between the two options too, which came for free via Bootstrap 4 and I really like it.

I’ve been working on completely extracting the membership code.

Would you have any interest in seeing video tutorials on how to make your own Symfony bundles?

Leave a comment and let me know.

There’s some other cool features that this work enables, which I’ll share with you in a future update.

Until next time, have a great weekend and happy coding.


The First Symfony 4 Tutorial Is Here

This week saw six new videos added to the site.

These are the final four in the Docker Tutorial for Beginners series, and the first two in the Beginners Symfony 4 Tutorial series.

A tutorial on Symfony 4 has been highly requested since it released on 30th November 2017.

Since then we’ve had three patches, so we’re now on Symfony 4.0.3.

Have you tried it yet?

I Had My Doubts

I will be completely honest, for the longest time Symfony 4 scared me.

We switched from the Symfony 2 / Symfony 3 Standard Edition, to the Symfony 4 skeleton. From a nice “full stack” to a minimal, bare bones starting point.

The first time I used Symfony 4, I just couldn’t wrap my head around why they would remove most of the very useful things:

  • Monolog
  • Twig
  • Routing…

And then the more I read, the more I thought that the symfony/skeleton was taking Symfony to become a replacement Silex. And whilst I have used and quite like Silex, I preferred the Symfony Standard Edition / full-stack approach.

I also went into a panic as I thought pretty much everything on the CodeReviewVideos.com would be obsolete.

Moar Skellingtons

Thankfully, all my fears were eliminated when they released the  symfony/website-skeleton.

For me, this is perfect.

All the benefits of why I use Symfony for all my web projects, with all the added new features and bug fixes.

And a bare bones edition for my command line apps.

My Favourite Video

Even though this is a Symfony 4 beginners series, the last two videos get a little geeky. I can’t help myself.

There’s a really interesting change in Symfony 4 with the way we use controllers.

It’s useful to know as a beginner, and hopefully it sparks your curiosity into knowing more about the “how” and “why” of Symfony generally.

This one should be useful even if you’re not a beginner.

Other Stuff

There’s a lot of other change in progress at the moment, particularly on the back end of the site.

I’ve been putting some of the front end tweaks live this morning, and these take on board the suggestions I’ve had from site visitors. Thank you for all your feedback I really appreciate it.

There are still 15 or so videos to come from this batch. I’m currently taking a break from editing to write this.

Ok, on that note, have a great weekend, and happy coding.

Chris – CodeReviewVideos.com

How I Fixed: “error authorizing context: authorization token required”

I love me some Dockerised GitLab. I have the full CI thing going on, with a private registry for all my Docker images that are created during the CI process.

It all works real nice.

Until that Saturday night, when suddenly, it doesn’t.

Though it sounds like I’m going off on a tangent, it’s important to this story that you know I recently I changed my home broadband ISP.

I host one of my GitLab instances at my house. All my GitLab instances are now Dockerised, managed by Rancher.

I knew that as part of switching ISPs, there might (read: 100% would) be “fun” with firewalls, and ports, and all that jazz.

I thought I’d got everything sorted, and largely, I had.

Except I decided that whilst all this commotion was taking place, I would slightly rejig my infrastructure.

I use LetsEncrypt for SSL. I use the LetsEncrypt certs for this particular GitLab’s private registry.

I had the LetsEncrypt container on one node, and I was accessing the certs via a file share. It seemed pointless, and added complexity (the afore mentioned extra firewall rules), which I could remove if I moved the container on to the same box as the GitLab instance.

I made this move.

Things worked, and I felt good.

Then, a week or so later, I made some code changes and pushed.

The build failed almost immediately. Not what I needed on a Saturday night.

In the build logs I could see this:

This happened when the CI process was trying to log in to the private registry.

After a bit of head scratching, I tried from my local machine and sure enough I got the same message.

My Solution

As so many of my problems seem to, it boiled down to permissions.

Rather than copy the certs over from the original node, I let LetsEncrypt generate some new ones. Why not, right?

This process worked.

The GitLab and the Registry containers used a bind mounted volume to access the LetsEncrypt cert inside the container on the path /certs/.

When opening each container, I would be logged in as root.

Root being root, I had full permissions. I checked each file with a cheeky cat and visually confirmed that all looked good.

GitLab doesn’t run as root, however, and as the files were owned by root, and had 600 permissions:

The user GitLab is running as doesn’t have permission to read the private key.

Some more error output that may help future Googlers:


Thankfully I hadn’t deleted the old cert, so I went back and saw that I had previously set 0640  on the private key in the old setup.

Directory permissions for the certs was set to 0750 with execute being required as well as read.

In my case this was sufficient to satisfy GitLab.

When making the change on the new node, I could then immediately log back in.

A Tip To Spot This Sooner

I would strongly recommend that you schedule your project to run a build every ~24 hours, even if nothing has changed.

This will catch weird quirks that aren’t related to your project, but have inadvertently broken your project’s build.

It’s much easier to diagnose problems whilst they are fresh in your mind.

Also, ya’ know, better documentation! This is exactly why I’m now writing this post. So in the future when I inevitable make a similar mistake, I now know where to look first 🙂

How I Fixed: “Authentication request could not be processed due to a system problem. “

Sometimes the simple stuff seems the hardest.

In my case I am working through the Symfony 4 update to the Symfony Deployment course and somewhat unusually, am not doing anything in dev, but lots of stuff in prod.

The reason for this is that I have forked the official Symfony demo project, and have slightly modified it for my needs. As it’s an official demo project, it’s pretty much guaranteed to work.

I had a production server set up, and had deployed my code.

I’d set up my environment variables – I believed, correctly. But when I hit the site:

“Authentication request could not be processed due to a system problem.”

I do enjoy a good error message.

The fix was simple in my case. I had set the wrong path to the database:

And what it should have been:

The db name was back to front.

In prod, the log files give no help around this, at all.

I had to spin up the dev environment where things are a lot more evident:

The give away line being:

Typos, such fun.

Anyway, easier to fix than it might otherwise appear. Hopefully it is for you, too.