PHP weirdness

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.

Problem 1

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

Solutions?

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.

 

 

Advertisements

So I decided to install Java …

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 had used Selenium for testing several years ago. I remembered that all I had to do was fire up the Selenium server and run the tests to catch any Javascript browser issues. I remember that being very helpful, so I downloaded the Selenium server and tried to fire it up. … Wait a minute. I don’t have java on this machine any more? The OS upgrades probably turned it to toast. OK. I’ll install that first.

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 update
> 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 should have known that.

Recently, I upgraded my laptop to run macOS Sierra. Along with the OS updates, I also used brew to update python3. I was not paying attention and ended up upgrading PostgreSQL to the newest version, 9.6.2. I was unhappy that I was not paying attention, but I was glad that upgrades to PostgreSQL and MongoDB were also done with the upgrade to Python 3.

I use brew to start and stop PostgreSQL as needed, so I started it to check to see how it ran after the update. ‘psql’ gave me a version number, but I could not get it started to show me the schemas or tables from previous work. I also saw the following error message:

psql: could not connect to server: no such file or directory
Is the server running locally and accepting
connections on Unix domain socket “/tmp/.s.PGSQL.5432”?

Very strange error message, so I started doing Google searches to see what could be wrong. There some dead ends involving checking for a PID file and checking permissions in /usr/local/var/postgres. Eventually, I ran into what looks like the answer in two related locations: a blog post describing upgrades to PostgreSQL and another one describing the upgrade process using brew. Apparently, I had two versions of PostgreSQL on my machine.

> brew info postgresql

confirmed it. Both pages described what I have to do, so I’ll do it. I should have known I needed to do this. Now I know.

Catching up with Python

I always forget that major software upgrades in OS X reset permissions in /usr/local. When I checked my brew install, I saw that message. I played around with write permissions only, but in the end, did what brew recommended and reset the permissions as described. That allowed me to update brew and move on to the next task: updating Python3.

I was not as far back as I expected. I was sitting on Python 3.4. The upgrades went smoothly and I’m back to Python 3.5.1. I thought I had modules installed, but I’m not getting any list of local modules installed. It’s very possible, since I never did much with on the desktop. That will be the next task.

odd home-brew issue with permissions,

I was going to update files installed through home brew and I noticed an odd error message:

Error: unable to unlink old ‘share/man/man1/brew.1’ (Permission denied)

or something like that. That’s never happened before. /usr/local should not have a permissions problem, unless MySQL is involved somehow. (B’). I run ‘brew doctor’ on the command line and it suggests permission fixes for /usr/local/bin/, /usr/local/share, /usr/local/share/man and /usr/local/share/man/man (?). Why did this happen?

I know that “rootless” access is being enabled in OS X 10.11, El Capitan. The idea is this “System Integrity Protection” will make it difficult for malware to install itself in /System, /bin, /sbin, and /usr. However, /usr/local was supposed to be left alone. Also, I’m running Yosemite, not El Cap. Even so, I need to run my updates, so I run the following in Terminal

sudo chown -R “$USER”:admin /usr/local/bin

sudo chown -R “$USER”:admin /usr/local/share

When I run “brew update” again, my system is ready for brewing.

From what I can tell, it looks like folder permissions may be reset during each system software update. I can’t confirm it, but it makes sense. If I had problems after a system update, I would run the Disk Utility and have it repair permissions. Usually, whatever problem I had would go away. It looks like OS X wants to be helpful, but also interferes with the way I have things set up. I’ll make it work.

reloading files … not fun

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?

More composer notes

When I decided to investigate PHP frameworks, I discovered that lots of them required Composer  (https://getcomposer.org) for full installation. It makes sense, since Composer is a “dependency manager for PHP” and serves to collect everything needed for a PHP application. I like the idea of having something that can install everything needed at once, so I decided to install it.

I use Homebrew (http://brew.sh) as my package manager, so I had it install composer as a global package. It installed composer 1.0.0-alpha9. As described in another post, I ran into some problems installing CakePHP that were eventually resolved, more or less. I still had some trouble using Composer to install CakePHP, but I did get the pieces to install using a full CakePHP download from their site (http://cakephp.org). I was a little disappointed that Composer did not work as expected, but I got what I needed, so I moved on.

Eventually, I became comfortable enough with Bootstrap to install a Bootstrap plugin into CakePHP. The plugin instructions said to update the CakePHP composer.json file and then update it. I tried that, but I had trouble with parsing of a composer package version: “>=0.4.2 <1.0”. It looks fine, but my copy of Composer stopped over and over again. I installed a new local copy of composer and ran a dry run to see what would happen. This time, there were no freezes. I don’t like the idea of having local copies of composer sprinkled throughout the file system, so I did more research.

I tried using brew to update the composer package, but it would stop with errors. The error messages mentioned I did not have a copies of PHP in the brew directories. That’s true. I did not want to install additional copies of PHP when Apple provided an slightly order, but working copy. I managed to install composer before, but the trick I used then did not work now.

After reading the documentation (who does that?), I discovered that I could get composer to update itself. After running the self update, composer finally updated itself to the latest stable version. The syntax issue that caused problems before was fixed. I was able to update CakePHP to 3.0.5 and also successfully installed the Bootstrap plugin. On to the next issue.