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’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.
My workstation has a weird short circuit somewhere that has to be tracked down at the help desk. While I wait, I’ve tried to install my work on the department laptop. It has not been easy.
Luckily I pushed copies of what I was working into repositories for off-site storage. Unfortunately, those repositories were slightly out of date. I did not lose anything from the database archives, from what I can tell. The CakePHP 3 repo is about two weeks out of date. I convinced myself it was OK, since I spent two weeks trying to solve a dead end regarding JQuery, AJAX and calls back to the original CakePHP action. It should be easy, but I have not been able to track down the answer yet.
I cloned the archive repository locally and reloaded that SQL into the local copy of MySQL. That went fine, with some minor issues. You can’t load a table with foreign keys until after those related tables are loaded first. (Of course.) If the file is too big to load through phpMyAdmin’s 2 MB file limit, zip it and try again. (That answer was staring at me all day long. Very annoying, once I found it.) Everything looks fine, so I move on to the next action.
Next, I needed to reload the CakePHP repository. Installing CakePHP is a little more involved than cloning a repository. For starters, the docs say I need Composer to install, which is not loaded on the laptop. I’m not sure why that would be needed for a repository clone, but why not? It can’t hurt, and I might need it, so I load Composer using homebrew. I found my old instructions for installing composer, but I forgot the final instruction, about ignore dependencies. I’m sure I thought it was obvious at the time, but it’s better if I remember putting it in. Finally, Composer is loaded, updated and ready to go.
Next, I remember that CakePHP needs specific PHP extensions to run properly (mbstring, openssl, and intl). The one I did not have was the intl extension. I checked my notes again and found a very good description of how to install the intl extension. That’s done, finally. I’m ready for CakePHP.
I clone the CakePHP repository. When I try to load it, it bombs. I get an error about permissions denied in the logs folder. I remember this error from another installation, so I’m confident I can track down the issue. I also notice that the vendors directory is empty. Now that I have the composer.json file, I update Composer and run it again. The vendors directory is back, but I still have the permissions problem.
While checking the vendors directory, I went to the config directory for some reason. I noticed that my config/app.php file is missing. That’s odd. The app.php file controls database access, so I’m surprised to see it’s missing. I finally get access to the Time Machine drive of the old machine and copy the latest version of that app.php file over. The permissions problem is not solved, so I decide to start from the basic installation with a test site described on the CakePHP web pages.
I stumble around, comparing user/group settings on folders between the fresh install and the Time Machine backup. Eventually, I get them set to something that looks like it works. However, the links to the CakePHP css pages are not working. I remember this again from a previous install. This has to do with apache and how it blocks access to .htaccess files (or something like that.)
I track down the section in the CakePHP documentation regarding URL rewriting, so I figure out how to set apache properly to get it to read CakePHP’s .htaccess file. While there, I find a related link that tells me exactly how to fix the logs and tmp directory. I’m almost ready, except for the part where my archives have disappeared. Somehow, they tables I loaded disappeared at some point. Very strange. This is important since I built a small website that uses CakePHP to display the data in the archive tables. Next stop. What happened to the archive tables?