Well, friends, here we are, back at it with the Drupal project.
The following events took place a couple weekends back. I was simply too busy at the time to post my documentation, and too busy since then to come back to it, as well…
To recap, I was last faced with a decision of what to do about my OpenSSL inadequacies. Basically, 1) find a way to upgrade within OS 10.11, 2) find a way to make Composer ignore the problem, or 3) upgrade to a mac OS that has a satisfactory default version of OpenSSL.
I’m going with option 1 first. So today I’m spending some time searching for issues related to upgrading OpenSSL in my good friend, The Captain (El Capitan, in case you haven’t read the previous post). After reading through a few Stack Overflow posts related to this, I was able to verify that my brew install did, in fact, put an acceptable version of OpenSSL on my computer, 1.0.2o. So, now I need to figure out how to get Composer to see and accept this and I think we’re in business.
According to this response in Stack Oveflow, I might just need to start a new bash shell: https://stackoverflow.com/questions/39824045/openssl-not-getting-linked-with-homebrew. Well, that seems likely. I’ve had several shells open since the beginning of this project. The sessions even continued after relaunching the computer. I was worried about losing any of the history of what I have attempted so far, so I kept them going. So, now I’ve just saved their contents as rtf files and will relaunch a new bash terminal and try installing Drupal with composer again.
So, now with my new bash session, I use cd to navigate back into the dev_sites directory and then remove the failed exploring-japan directory with ‘rm -rf exploring-japan’. You can also do this by moving the failed directory to your trash can via Mac’s GUI, of course, but I’m getting myself comfortable with the command line, remember? There is a significant difference between the two methods that must be noted, however. Using Mac’s GUI, you must first move a file or directory to the trash can and then empty it if you wish to permanently delete it from your drive. There is no intermediary step with the command line. Once you remove it, it’s basically deleted, gone forever. I’m sure someone more familiar with the Mac/Linux/Unix command line knows of a way to restore deleted file, but I suspect there is some elevated level of effort involved. By default, a simple ‘rm ’ command will not do. You will get a warning that the directory cannot be removed because it isn’t empty. This is a built-in safety precaution I presume. Hence the addition of ‘-rf’ , which means ‘recursive force’ (recursive = the target directory and everything that’s inside it; force = ignore warnings). So… use this command cautiously. If you remove the wrong directory, like if you go too high up in the root order, you lose that directory (folder) and everything that’s inside it. You could potentially render your computer useless if there are no failsafes built into your OS. I’ve heard this is a known problem in several Linux systems, and since Mac OS is related, the potential for the same is there, though I have no intention of testing it out at present. Hmm… Might be fun to attempt after a backup, on a computer that doesn’t have anything crucial going on at the time…
Anyway, back to our story, our intrepid hero (me), has saved rtf files of his old bash sessions, closed his terminal, relaunched a new bash shell, and has once again run the ‘composer create-project’ command. And, sadly, we get the same failed download message complaining about the incorrect version of OpenSSL (-_-). So, we’re back to making Composer see, or link, to the recently installed, correct version of OpenSSL.
The install failed because OpenSSL has reverted to version 0.9.8zh, which I confirmed by checking the version in the terminal (‘OpenSSL version’). Seems like the brew install didn’t take? More likely I didn’t link it properly after the install. Another possibility is that it reverted after a system update, or even after a reboot. A little more soul (google) searching brought me to this Stack Overflow article (https://stackoverflow.com/questions/38670295/homebrew-refusing-to-link-openssl). I followed the instructions provided by mcgwier on Aug 2 ’16 at 0:58, entitled ‘Manually install and symlink’. These instructions appear to have gotten the updated OpenSSL version 1.0.2o to stick! And I’ve redirected my system to look in the newly created src directory for this version of OpenSSL. So we’ll try to install the Drupal project again. And it fails again (-_-).
So, more searching brings me here: https://www.youtube.com/watch?v=vT5luUaAcQ8. This fellow, Nate LeClair (I’m guessing on the spelling), provides a video tutorial and also introduces me to this site, https://php-osx.liip.ch/, which I am bookmarking post haste! I’m hoping this is the Godsend it appears to be! It looks like it will install an updated version of PHP for you and also provides instructions to ensure that your mac system (from OS X 10.6 Snow Leopard to Mac OS 10.13 High Sierra, as of this writing) can have versions of PHP from 5.3 to 7.2 (again, as of this writing), installed. I’m definitely giving this a go! Of course, all the solutions thus far have seemed like the last great hope until they failed…
Before following the instructions, I went back to my hosting account to verify which version of PHP I have available. I have a few, it looks like, but I’m going with 7.2, as it’s latest one available. So I will match that version in my local environment.
So. What happened this time? No error messages. So I guess that means I’ve successfully installed Drupal 8 with Composer. \(^o^)/
It’s 2AM at this point in my story, so I think I’m going to get some sleep and will review the install and see about next steps in the next day or so.
epilogue: This evening, before posting, I took a little time to reset the time zone to “America/New_York” in the file titled 99-liip-developer.ini that came with the PHP installation. I initially tried just using one of my text editors (tried with VS Code and Brackets), but kept getting permission errors when I tried to save the file. I ended up opening it in vim via the terminal using the sudo command.
My next plan will be to set up the remote Git repository, to see how the site looks in my local server and to actually get it up on my live server. I did, as mentioned previously, actually buy a domain name about a month ago, but a couple new ideas started swimming around in my head, so we’ll see what I ultimately decide to name the project at a little later date.
To be continued…
Tags: drupal 8, web development