Category: Code Review Videos

[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.

Chris

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:

DATABASE_URL=mysql://dbuser:dbpassword@127.0.0.1:3306/db_dev

And what it should have been:

DATABASE_URL=mysql://dbuser:dbpassword@127.0.0.1:3306/dev_db

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:

[2018-01-12 12:50:22] request.INFO: Matched route "security_login". {"route":"security_login","route_parameters":{"_controller":"App\\Controller\\SecurityController::login","_locale":"en","_route":"security_login"},"request_uri":"http://127.0.0.1:8000/en/login","method":"POST"} []
[2018-01-12 12:50:22] security.INFO: Authentication request failed. {"exception":"[object] (Symfony\\Component\\Security\\Core\\Exception\\AuthenticationServiceException(code: 0): An exception occurred in driver: SQLSTATE[HY000] [1044] Access denied for user 'dbuser'@'%' to database 'dev_db' at /tmp/symfony-4-demo-app/vendor/symfony/security/Core/Authentication/Provider/DaoAuthenticationProvider.php:85, Doctrine\\DBAL\\Exception\\ConnectionException(code: 0): An exception occurred in driver: SQLSTATE[HY000] [1044] Access denied for user 'dbuser'@'%' to database 'dev_db' at /tmp/symfony-4-demo-app/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php:108, Doctrine\\DBAL\\Driver\\PDOException(code: 1044): SQLSTATE[HY000] [1044] Access denied for user 'dbuser'@'%' to database 'dev_db' at /tmp/symfony-4-demo-app/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:47, PDOException(code: 1044): SQLSTATE[HY000] [1044] Access denied for user 'dbuser'@'%' to database 'dev_db' at /tmp/symfony-4-demo-app/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:43)"} []
[2018-01-12 12:50:22] security.DEBUG: Authentication failure, redirect triggered. {"failure_path":"security_login"} []
[2018-01-12 12:50:22] request.INFO: Matched route "security_login". {"route":"security_login","route_parameters":{"_contr

The give away line being:

Access denied for user 'dbuser'@'%' to database 'dev_db'

Typos, such fun.

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

 

Merry Christmas and a Happy New Year for 2018

This is the last you will be hearing from me – newsletter wise, at least – for 2017.

With that in mind I’d like to take this opportunity to say firstly a very big and sincere thank you to you for your support this year.

Whether your are a subscriber currently, have subscribed to the site in the past, or will be subscribing in the future, your support means a lot to me.

I’m really pleased with how things have progressed with CodeReviewVideos.com this year.

I launched the new site version, which whilst still a work-in-progress (and likely always will be) now is in line with almost everything new I’ve learned in the last four years.

I share everything I know on CodeReviewVideos.com, and from the feedback I’ve had this year (thank you!) I know it’s really helpful to many of you, too.

This site is all about saving you weeks, months, or even years off the amount of time it takes to learn a framework as big and (potentially) complex as Symfony.

There’s other great stuff on here too, like learning how to use Docker in the real world, and another of my personal favourites, React with Redux and Redux Saga all connected to a Symfony JSON API.

Video Update

This week saw three new videos added to the site.

#1 – Fixing Third Party Bundle Deprecations (Indirectly)

We’ve fixed the issues with Symfony’s code.

We’ve fixed the issues with our own code.

Now we must fix the issues with any third party bundles we are using.

In our case we have just one bundle – eightpoints/guzzle-bundle.

The issue we have is fairly common. If a bundle you use adds ‘stuff’ to the sidebar in the profiler, then you are almost certainly going to need to fix this issue. Well, I say you. What I really mean is you will need to hope your bundle maintainer has updated their code appropriately, or you have a few options:

  1. Don’t upgrade
  2. Fix it yourself (which may take a while to get merged)
  3. Fork it, and fix it yourself (hoorah, now you’re in open source)
  4. Be lucky and have the bundle maintainer already have updated it for you

We all hope for number 4, right?

Fortunately on eightpoints/guzzle-bundle we get lucky. This is fixed for us… but:

Always a but. This will mean we need to be on at least PHP 7. Actually thought, Symfony 4 needs PHP 7.1, so yeah… either way it’s time to come kicking and screaming in to the modern world of PHP. Good.

#2 – [Part 1/2] Migrating to Symfony 4.0 with Flex

The recommended approach for upgrading to Symfony 4 with Flex is to start a brand new Flex project, and then migrate code between the old project, and the new.

This brings a potential problem:

When you create the new Flex project you will, by default, get a git repo created on your local computer.

For the love of Mike, don’t do what I did and accidentally copy that git directory over your existing git directory. Whoops. I share for the comedy, and fortunately it didn’t cost me any, because that was during the write up, and I re-do the whole thing again for the video. I bet you don’t want to do things twice though 🙂

There’s a bunch of steps to work through, some easier than others. You won’t believe step 5! Ho, ho, a buzz feed style bit of link bait title nonsense.

No, but seriously, step 5 needs some extra attention so be sure to watch the video to learn what that is.

#3 – [Part 2/2] Migrating to Symfony 4.0 with Flex

Finally we finish up the Symfony 4 migration by moving over the src  directory contents from the old Symfony 3.4 project to the new Symfony 4 Flex approach.

We then move over the Twig templates. There’s more work to be done here, and some of the problems we will face are not very intuitive. I guess it depends on how much you’ve been following the changes made in Symfony 4.

It really does feel good to have migrated a complete project, regardless of the project’s size, from Symfony 3 to Symfony 4. There’s some serious sense of satisfaction in seeing everything continue to work, even with such a massive amount of change behind the scenes.

Here’s to 2018

Whatever you are up to in 2018 I sincerely wish you every success.

Thank you and happy Christmas!

Chris

Refactoring Legacy Code

Last week I started the journey of updating all the existing tutorial content from Symfony 2 and Symfony 3 up to Symfony 4.

I mentioned that I don’t plan on recording a video for every single migration.

I also mentioned that I would be covering the most requested content first. That’s why I started with the GitHut series, with which most site users who are brand new to Symfony take their first steps.

So far I’ve written 9000 words on updating from Symfony 3 to Symfony 4.

Nine thousand words.

I was staggered by this.

It’s left me wondering exactly who this content is aimed at? I can’t imagine a beginner taking a 6 video (7 including the bonus) course, and then thinking a further 6 videos on updating this small project to Symfony 4 is something that makes sense.

Also, the project is for beginners so I can’t imagine too many experienced developers using this as reference, either.

Anyway, I’ve started so I’ll finish.

As a heads up, whilst I’m updating these projects there are very likely to be a few weeks without some new videos. I have a limited amount of time per week to create new content, and the general consensus from support tickets is that updating existing content is preferable to new content.

Video Update

This week saw three new videos added to the site.

#1 – What happened to my Web Server?

This change happened earlier than in Symfony 3.4, but as we are using the GitHut project as the base of this series, we are impacted by this change.

If you aren’t aware, as of Symfony 3.3 the web server (available via bin/console server:start ) was extracted out into a separate bundle.

In hindsight this foretold the way that most things in Symfony would become – opt-in, rather than opt-out.

Anyway, removing the web server bundle is potentially unexpected, and adding it back in is the first in a list of tasks that we need to do to migrate from Symfony 3 to Symfony 4.

#2 – Fixing Generic Symfony Deprecations

Whatever your Symfony 3 application does currently, as soon as you upgrade to Symfony 3.4 you’re going to get a whole slew of deprecation warnings.

This is code that must be addressed by us as developers, if we are going to upgrade to Symfony 4.

Simply put, if we don’t fix these problems and then blindly update to Symfony 4 then our site will (most likely) just stop working.

A lot of these deprecation warnings sound complicated but are really just about adding in a speech mark here, or a new line there. Often if unsure, a quick Google is enough to see you right.

Even so, there are a bunch of these to cover and if you’re brand new to Symfony then this might not be a super easy task to complete. But don’t worry, this tutorial walks you through each fix, step by step.

#3 – Fixing Deprecations In Our Own Code

Whilst the previous video tackled problems that you’ll find in most every Symfony code base, in this video we look at specific problems to our own code.

It’s telling that even though the GitHut app is very simple compared to most real world projects, we still have a bunch of issues to solve. When I’ve approached this task on my own real world projects, the list of deprecations can be large and off-putting.

In this video we cover one of the most frequent problems you will encounter:

Legacy service definitions.

You may have already started using the new approach to Dependency Injection, and if so, you’re going to have a head start in this battle.

If you haven’t then now is the time to jump in and start learning some new stuff.

Ok, that’s it from me this week. Short and sweet.

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

Chris

Symfony 4 Tutorial Content Update

Symfony 4 has caused me a few headaches this week. In between the usual site work, I’ve been tackling a noticeable up-tick in support requests regarding video content.

There are a number of reasons why this is, some of my own making.

Anyway, though I had planned to work on finishing each of the currently in-progress courses, I am instead switching to updating every existing Symfony related course on the site to use Symfony 4.

I’m honestly not sure how much work this will involve at this stage. I’m expecting it to take a few human days in total, which I unfortunately don’t have in one large block.

What this will mean is for each course I will pull the code from GitHub, and add a new branch, or branches, to enable support for Symfony 4.

I don’t expect, nor plan to have to update every video.

I do expect to have to record some new video content around updating some of the bigger projects.

I’m going to work on the courses based on the volume I’ve been receiving in support requests.

I’ll know and share more on this next week.

Video Update

This week saw three new videos added to the site.

#1 – Simple Backup Shell Script Linux

Backing stuff up is a real chore.

During development it’s not that big of a deal. Sure, if we accidentally destroy the DB it *might* be a pain, but it’s unlikely to cost us our jobs, or make national news (or, at least, hackernews).

Once we hit production however, backups are up there with the toppest of top priorities.

I guess we could do manual backups. It’s a good way to waste 30 minutes every day by following some regimented process.

A better way is to delegate to our robotic helper: the computer.

In this video we cover a basic but “good enough” (for me, at least) method of backing up pretty much anything, and keeping only the last X backups (where X may be 7 days for example).

We’ll cover how to write a backup script using Bash shell scripting, and how to automate running that script using a cronjob.

#2 – How to change the DB with a Phoenix Migration

Most every application I work on involves the database in some way.

When starting a fresh application it’s fairly easy to remember how and why the database schema ended up the way it is.

Then, after chopping and changing between four other projects, I come back to this “small” project and I’ve forgotten everything about it. Including why one of the fields is inexplicably an integer when a boolean seems like it might have been a better choice.

Fortunately, if you’re using database migrations, you can easily check back through the Git logs and figure out just what was changing in the code when you made such an interesting schema change.

I once read, somewhere, that having database migrations is effectively like adding version control to your database. I’m not entirely convinced by this, but they are helpful, and have proved worthwhile for me over the last few years.

Whatever your opinion, database migrations are available to us right “out of the box” with Phoenix, so using them is a no-brainer.

#3 – Database Schema: What and Why

In the previous video we covered how to tell the database about our changes, be it adding a new table, editing an existing table, adding or updating an index, and so on.

In order to work with that table we must write some Elixir code that represents that table.

A schemer

This code is called a Schema.

In this video we cover how we can generate a Schema for any particular table, and what the generated code is doing for us, and why.

Once we have a Schema, in this case for our “Contact”, we can start adding new records to the database. And we will do just this by making use of the REPL.

There are some interesting extras included in this video, such as touching on the purpose of alias, working with dates and times, and our first encounter with Pattern Matching.

That’s a Wrap

Ok, that’s it from me this week.

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

Chris