Now that we have a site archive file, we need to get this imported into our Pantheon account. In this tutorial we will do just that. In the process we will look at the two different interfaces for doing an import. For our single-file site archive, we can use the default interface, but if you have three separate files for the database, code base, and files, we'll look at how to get those uploaded as well. If your site is too large to import using the Pantheon dashboard UI, then you should check out the instructions for Importing a Large Site on the Pantheon website.
Additional resources
Importing an Existing Drupal Site to Pantheon (pantheon.io)
Importing a Large Site (pantheon.io)
In this tutorial you'll learn how to access and use each Pantheon environment. We'll start by assuming we have done a bunch of work in our initial Dev environment and we're ready to create the Test and Live environments. Once we have all three environments up and running, we'll make some changes to our site code in Dev. With that done we'll merge the code changes in Dev with the Live database in Test so we can make sure everything looks good. We'll also run a site check on Test. Once everything looks clear, we'll deploy the code changes to the Live environment. After deployment we'll see how to pull the Live database back down to our Dev environment whenever we need to.
You can access your code using either SFTP or Git. In this tutorial we'll be using Git. If you'd like to learn more about Git, or get a refresher, you can watch our Introduction to Git Series.
Additional resources
Using the Pantheon Workflow (pantheon.io)
Introduction to Git video series
What Is Pantheon?
FreePantheon is more than just a hosting service. It is a powerful tool to manage your websites, and handle deployments. Pantheon provides a great framework for development best practices as well as making sure the platform you are running on is truly optimized for Drupal sites. In this overview presentation we'll introduce you to the features Pantheon provides and why you would use them to host your Drupal sites.
Additional resources
In this tutorial we're going to dive into using Pantheon's Multidev feature. To demonstrate how this works we'll first create a new Multidev environment by cloning the existing Dev environment. Once switched over to this new branch in Git, we'll quickly edit some code and push that to our repo. We'll use Multidev to review the new code in our dashboard, and then merge that branch into the Dev master branch. With the full process complete, we can delete that branch, and the environment with it.
Additional resources
Pantheon Multidev Workflow (pantheon.io)
In the last tutorial we created a new site from scratch on Pantheon. What if you already have a site that you want to move to Pantheon though? In this tutorial we'll provide an overview of how to import your site into Pantheon. We'll discuss what the various parts of a site are that you need to work with, and some important points about what Pantheon expects. We'll also discuss the different methods you can use to import your site and the guidelines for which method to use, especially when working with large Drupal sites.
Additional resources
Importing an Existing Drupal Site to Pantheon (pantheon.io)
In this tutorial, you will learn how to get a Drupalize.Me tutorial demo site up and running using Pantheon. You'll learn about the various components that make up the Drupalize.Me demo site downloads and how each part should be imported. By the end of this lesson, you'll know how to create a Drupalize.Me demo site on a free Pantheon Dev instance so that you can follow along with the trainer in the Drupalize.Me video tutorial.
Additional resources
In this tutorial, you will learn how to use Acquia Dev Desktop 2 to get a Drupalize.Me tutorial demo site up and running. You will learn how to import a Drupal codebase and database containing a finished site for an individual tutorial on Drupalize.Me. This will enable you to walk through the lesson and see what was accomplished on the site during the lesson.
Additional resources
Pausing Our Podcast
Blog postThis week, instead of publishing a regular podcast episode, we recorded a short update about the podcast itself. We're not producing any more episodes for the rest of 2015, but you can look forward to a new, better podcast in 2016.
Release Day: Object-Oriented PHP Part 2
Blog postWe've recently switched from weekly releases to working towards releasing an entire series all on the same day. The Object-Oriented PHP Part 2 series is the first one we're doing with this. You get access to the complete series today! This second part of three on object-oriented PHP, provided by KnpUniversity, continues on from our Introduction to Object-Oriented PHP series.
So far we have to create our service objects by hand and this stuff is duplicated. We need to centralize our service objects to make our lives easier. To do that, in this tutorial we'll create one special class whose only job is to create these service objects. This class is called a service container because, well, it's basically a container for all the service objects. We're going to create our service container and then update our code to use it properly.
In the prevous tutorial we set up our app to fetch the ship objects from the database, but now our app ship select lists are not working properly. To deal with that, in this PHP tutorial, we're going to add a ship ID property to our class and then we will use the ShipLoader
class to query for individual ships. Lastly, we will once again need to turn the array that we fetch into an object that our app can use. As an added bonus we'll also update the PHPDoc so we can get autocompleting method names.
Things are working pretty well, but we still have some things to clean up. In this tutorial we're going to review some best practices. Our current problem is that at the bottom of ShipLoader
, our database connection information is hard-coded. That's a problem for two reasons. First, if this works on my computer, it probably won't work on production, unless everything matches up. Secondly, what if we need a database connection inside some other class? Right now, we'd just have to copy and paste those credentials into yet another spot, which is definitely not ideal.
Here's the goal: move the database configuration out of this class to somewhere more central so it can be re-used. The way you do this is fundamentally important to using object-oriented code correctly. The concept we are going to implement here is called dependency injection. The idea here is don't put configuration inside of a service class. Replace that hard-coded configuration with an argument. This allows anyone using your class to pass in whatever they want. The hard-coding is gone, and your class is more flexible.
Additional resources
Dependency Injection and the Art of Services and Containers series
PHP Service Classes
FreeIn this course, we're going to continue on from the Introduction to Object-Oriented PHP series. We're working on the same spaceship project: it has ships, you choose them, then they engage in epic battle!
In an editor, far far away, you'll see a simple application that runs this: index.php is the homepage and battle.php does the magic and shows the results. In the first course, we created a single class called Ship
, which describes all its properties—it's like a container for one ship's details. In this tutorial we're going to replace our flat functions and create a BattleManager
service class to provide the methods we'll need to do that.
Our database is working well, but we currently have things set up so we are duplicating the database information, and that is going to be a nightmare to maintain. In this tutorial, we're going to clean up our database code by isolating the PDO
creation in the ShipLoader
class. Even with that in place though, we also need to make sure we only return one PDO
object. We don't need a new database connection every time it gets called on a page. We'll fix that with a little bit of logic in our PDO
code.
We now have a BattleResult
class, and we type-hinted the two Ship
arguments. But now, if you look at the battle()
function, there's a case where the ships can destroy each other. When that happens, there is no winning or losing ship—they're both null. Since null
is not a Ship
object, PHP gets angry and throws an error. In this PHP tutorial we'll fix that problem by creating a isThereAWinner
semantic method in our BattleResult
class.
So far we've been hard-coding our ships in the ShipLoader
class. In this tutorial we'll take things up a notch by fetching that information from a database. First we're going to create a new database to hold our data, using PDO
. (If you are not familiar with working with databases in PHP, you can check out the PHP for Beginners Part 3 series, which covers database fun.) Once we have the database created and filled with some ship data, we'll learn how to fetch that data back out again as an object our app can work with.
To wrap things up with our app, the last bit of housekeeping is to make one container responsible for creating every service object, like PDO, but also ShipLoader
and BattleManager
. The problem is that if we called $container->getPDO()
twice on the same request, we'd still end up with multiple PDO
objects, and so, multiple database connections. Ok, if we're careful, we can avoid this. We can do better though—let's guarantee that only one PDO
object is ever created. We did this previously in ShipLoader
, so now we'll move this into our container.
The next thing we want to tackle is our battle()
function, with its array, inside our BattleManager class. It's not obvious at all what's inside the $outcome
variable, or whether the keys it has now might be missing or different in the future. To rectify this we're going to create a new BattleResult model class with some properties and methods that will clean things up and remove the need for weird associative arrays. Our BattleManager::battle()
function will return a nice BattleResult object, and we'll be in full control of what public methods we put on that.
Related to the previous tutorial where we implemented best practices to centralize our configuration, we also want to minimize the number of database connections. We want one connection that every class uses. In this tutorial we'll move the new PDO()
call out of ShipLoader
so that it can be created in a central location and used by everyone. How? By using the same strategy we just learned with configuration. If you want to move something out of a service class, add it as a __construct()
argument and pass it in.