I updated to Mojave. I remembered (again) that /etc/apache2/httpd.conf gets reset. This means that Apache may serve up local web pages, but local php sites may stop working. As always, I follow the instructions here to review how to get PHP working again. It’s an easy fix and PHP now runs again. What’s new? PHP 7 on the local machine as default. Hmm … I know I’m behind. It’s been a busy year.
I thought it would be interesting to set up a Laravel instance to try it out. I did have a new project I wanted to develop, so I thought “How hard can it be to set up Laravel”? Well …
I have started using Vagrant to run some VMs (instead of VirtualBox by itself). I found the homestead box in the Vagrant Cloud, so I set that up to download and install.
> mkdir ~/Vagrant/laravel
> cd !!:$
> vagrant box add laravel/homestead
I wait a long while to download, but it finally arrives. I start it and look around, but I don’t see any of the programs I’m told will be associated with Homestead (mysql, nginx, etc). That’s odd.
The Laravel homestead documents also suggest cloning a repository. That did not make any sense, since I had a running Vagrant box. Since nothing was happening, I thought “Why not?”. The clone is downloaded into the same folder as the Laravel Vagrantfile. I follow the instructions to set up a Homestead.yaml file and look inside the Homestead folder to see if it’s there. It is, along with lots of others stuff, including … another Vagrantfile … That’s weird.
I make some simple changes to homestead.yaml and reload the original Vagrant box.
> vagrant reload –provision
I don’t see my changes. After some time, I wonder … What if I went inside the cloned folder and ran that Vagrantfile? It turns out that second Vagrantfile is the one that runs the homestead install. It seems weird to have a homestead box available in the Vagrant cloud and NOT have it be the one to use, but that’s what happened.
I make some changes in the homestead.yaml to set up a simple test site using the classic php test file.
<?php phpinfo(); ?>
Nothing displays. My first error message says “No input file specified”. I fixed that by pointing the map section inside homestead.yaml to the correct folder. Next error: “403 prohibited”. I thought it might be an nginx error, but I did not want to mess around too much with that just yet. However, I did check /var/log/nginx/homestead.test-error.log and I noticed something interesting:
“Unable to open primary script: /home/vagrant/code/test01/public/index.php (No such file or directory)”
OK. I guess I must wrap the simple php test page inside a Laravel template to make it display. Not a big deal, but one more thing I need to figure out. That will be for next time.
You may or may not know that I like boardgames. I like playing them. I like organizing them. I like tracking what I’ve played recently and what needs to be played again. One of those games is called “Advanced Squad Leader” (ASL). Honestly, it’s so big it could be called a boardgame life style. I don’t have enough time to play it regularly. All I can do is try to stay current with parts like modules, game boards and game scenarios.
Many years ago, I started writing a web application that would help me track all the parts that came with ASL. (It’s that big.) Game scenarios come with game modules and also come separately in scenario packs and magazines. I would frequently run into this situation: I find a game scenario that looks interesting, but do I own all the parts needed? The web app was supposed to supply that information.
I remember starting on this project back when I felt Dreamweaver was limiting my development as a programmer (2006?) At that time, I was impressed with Smarty as a PHP template engine. Smarty 2 became Smarty 3 eventually. Composer allowed me to load the Smarty libraries as a vendor module. I started using Bootstrap 3 (4 coming out of beta soon) to handle css design work that I did not want to do.
The web app has sections where the user can look up specifics about the game set owned, among other things. There is an admin section in the site that was supposed to handle updates to boards, modules, scenarios and overlays. In the refactored version, I built a admin section that was supposed to be a landing page for a successful administrator login. Unfortunately, it did not work.
I had problems displaying the associated Smarty template file for a page that was not on the top level, but inside a directory on the top level. It did not matter which smarty template file was tried with the new admin page. It would not display. Aha!
It’s not a problem with a specific template file, but a larger issue with paths, somehow. I went as far as giving an absolute path to the Smarty template engine for the correct template file, but … (new problem) I was having trouble writing a compiled template file. Aha! Another clue.
It turns out that I was using relative paths in one of my include files that described where to find the Smarty template directories. Once I fixed the paths and made them absolute using $_SERVER[‘DOCUMENT_ROOT’], the problems went away. That was a nice problem to track down on a weekend of coding.
I’m not sure I’ll stick with the Smarty template library going forward. Twig (associated with Symfony) and Blade (associated with Laravel) look useful to know. Twig reminds me of Jinja2, so that would be an easier transition. I can still make Smarty work, though, even though the docs style pages remind me of 2006.
I use the stock PHP version installed for macOS Sierra. In my case, it’s PHP 5.6.30. It runs well on my local web apps and it’s useful for my development environment.
I’m not going to stick with it forever. The vagrant environment in Laravel (Homestead) uses PHP 7. The vagrant machine I’ve seen recommended for development comes with PHP 7. I’ll move to it eventually.
During the spring, I was trying to clean up my brew environment to allow for a cleaner install. I paid attention to the warnings, but I accidentally ran “brew upgrade” without any modifiers. I ended up installing a ton of stuff that I don’t use regularly, including PHP 7. “brew services” shows that it’s not running, so that’s OK, but still … I was not paying attention and now I have PHP 7.
I use composer to keep all my PHP packages and modules updated and tracked. I added a new module to a composer.json file, so I needed to update it. I ran composer and I got the following message:
“Your requirements could not be resolved to an installable set of packages.
– This package requires php ^5.5.38 but your PHP version (7.0.15) does not satisfy that requirement.”
It turns out that “which php” points to /usr/local/bin/php, which is the home brew install. When I check $PATH, it turns out that /usr/local/bin appears before /usr/bin, where the stock install of PHP 5 is located. That’s why PHP 7 is the PHP appearing in the command line.
1. Change the $PATH order
No! This is a bad idea. By changing this, a lot of the home brew installs will use the wrong version. It seems too much effort to fix one item.
2. Update Apache to use PHP 7.
I have to do it anyway, just not now.
3. Change the php requirement in composer.json
I could change the requirement to “>=5.6.30” instead of “^5.5.38”. The ^ requires that PHP stay within PHP 5. ‘>=‘ only requires that the PHP version be greater than or equal to that number. It’s a band-aid, but it gets the updates running for tonight.
I’m not a Java coder. I work primarily in PHP, with Python on the side. I’ve been rewriting an old PHP project to conform with modern standards, including testing. I decided to use Codeception for PHP testing, mainly because it looked like PHPUnit was included and unit/integration/acceptance testing looked easy (if you follow the example given in the website). I had used Gherkin to write BDD tests, so I was happy to see it with PHP. I also saw auto-testing with PhpBrowser and … Selenium!
I spent a few days thinking about how to install it. Since I use brew to install other command-line applications, I wondered how brew would handle a JDK installation. It turns out that my Google search: “jdk homebrew” came up with several web pages that did not fully work. I had to put together instructions from these pages.
For starters, I ran into a command that mentioned casks. Eventually, after another Google search (“homebrew install cask”), I discovered that “cask” is a way of managing graphical applications through brew. Anyway, after some review, I finally have Java (1.8.0_131) running on my El Cap box. Yay, me! You’re welcome to try these or to review the pages linked above to figure out yourself. It looks like it will work either way.
> brew install caskroom/cask/brew-cask … (probably did nothing)
> brew tap caskroom/cask
> brew cask install java
Note that I did not choose to install “jenv”, which creates virtual environments similar to “virtualenv” or “venv” (?) with Python. Somewhere in one of these pages, there was a note that I needed to install Java 7 first. I never found a reason why it was needed, so I skipped it. We’ll see if I do need it.
I have some mini-projects that I would like to move off my laptop and onto the internet for further testing. Almost all my projects involve web-enabled databases, so I need to set up databases to handle the data used by the websites. For now, I want to stay away from NoSQL, which I something I don’t know yet. In that case, which to choose, MySQL or PostGres?
I’ve used MySQL forever. I think my first MySQL book (which I rarely use any more) discusses MySQL 3. I’ve appreciated the transition to MySQL 4, then 5. I know what it does. I have no trouble setting up MySQL PDO statements in PHP. I’m familiar with the MySQL Python modules and can also connect that way, too. However …
MySQL is owned by Oracle. Ever since it was bought by them, there has been an underlying question about how much support the community (free) edition would receive. Oracle’s latest financial snapshot came out recently (June 2016). They made most of their money with their cloud offering, as I understand it. They made no money in support or development. You have to wonder how much longer MySQL will keep going before it stagnates. I could move over to MariaDB, the “open source” version of MySQL, as strange as that sounds. I’m thinking that if I’m going to use a MySQL copy, why not use MySQL?
A few years ago, I took a Saas class through a Berkeley MOOC (CS 169, Agile Development Using Ruby on Rails). They set up accounts on Github and Heroku for their students. I liked how easy it was to migrate code and data onto the cloud using both platforms. My problem at the time was that I was not familiar with them, so it was one more thing I had to learn quickly while taking the class. Ruby favors Postgres as the database and Heroku made it easy to move the data through the command line interface installed through their app. If I’m going to host my projects on the cloud, then I should stick to what makes it easy.
However, I’m very familiar with MySQL. It’s easy to install. I know how to do basic hardening of the database. It’s easy to read/write to MySQL from PHP, using proper credentials. I’m starting over with Postgres. The stock version of PHP that comes with El Capitan does not handle PDO calls to Postgres by default. I have to compile them myself. Which Postgres do I install? Is Postgres.app really that much better? So many questions that I need to answer.
And now I’m looking at cloud services in addition to Heroku. AWS Elastic Beanstalk to use with Docker. Digital Ocean (super cheap). Linode (not as cheap, but I have considered them before.) Hmm …
I’m getting ready to install CakePHP 3.1.3 on my laptop. I discovered that I needed the intl PHP extension installed as a requirement for CakePHP. I tracked down several web pages with instructions and I decided to use this one, considering I had good luck with the page the last time I needed to install the intl extension. The page is for OS X Mavericks. I found no significant changes when I followed along for my Yosemite laptop. The only real change that I saw was that there was a new version of the ICU installer (56.1 as opposed to 52.1 described on the page).
I was surprised that I needed to install PECL and PEAR, considering that I don’t use PEAR that much any more. PEAR did not give me trouble. However, pecl.php.net was down the afternoon I wanted to install the software, so I had to wait until the next morning to install it.
Like I mentioned, the ICU installation instructions are almost the same. The only difference is the updated version of ICU, 56.1. Substituting the new version into the suggested Terminal commands went well
I thought I already had AutoConf installed, from what I saw in some libraries in /usr/local, but I decided to install it again to be sure. I had no trouble with it.
PECL gave me no trouble when I wanted to install the intl extension. Somehow, my php.ini file had been updated with the extension command pointing to intl.so. I thought that was odd, but I let it go. When I checked phpinfo(), there was a new entry for the intl extension. Very nice.