The project used a SQLite database, as the data stored is minimal (some hostnames and logins). On the testing servers, we had no problems using and working with these, and all needed parts happily talked to the datafiles. Alas, when running it on my Macbook Pro running Leopard, I got some errors from symfony, complaining the datafile was encrypted or no real sqlite datafile.

A quick check gave no real indication of the problem; the datafile appeared to be correct and worked using the CLI tools:

bernard:tmp bernard$ sqlite3 project.sqlite
SQLite version 3.4.0
Enter ".help" for instructions
sqlite> .tables
ftp_hosts_and_logins       sf_guard_remember_key
ftp_path                   sf_guard_user
sf_guard_group             sf_guard_user_group
sf_guard_group_permission  sf_guard_user_permission
sf_guard_permission
sqlite>

I even dumped the data to a text-file, and re-imported it using the cli-tools. Nothing helped, symfony (well, php) could not read the file. After a while, the problem was found. On Leopard, all the SQLite version 3 tools are included on the system, but in the PHP which is shipped with Leopard, the linked in library is version 2.

This would be no problem, but it seems Leopard ships without the SQLite version 2 cli tools, so there was no obvious way to convert this datafile to version 2 (or I should use the tools on the testing server, but then I had no way of using it from within my shell, which was no option).

This is just plain stupid. All libraries and tools are version 3, but the the linked library for PHP is version 2. Talk about forgetting something. As propel can’t work with PDO (another db layer in php), I either had to replace my PHP on Leopard with a custom-made one, or try to install the sqlite 2 tools. Neither seemed a good idea, I hate to replace my defaults with custom stuff.

It resulted in converting the SQLite database to MySQL and changing my symfony project to use the MySQL.

Each module in your application can be protected through the use of the security.yml files. In the top-level security.yml file, I included the following (it was a backend application, so access should be restricted, when in doubt):

default:
  is_secure: on

Now, if you want to protect a module, apparently, it doesn’t work to include this in your main config:

default:
  is_secure: on
 
module1:
  credentials: admin

However, when including this in your module1/config/security.yml file, it works (the ‘all’ concerns the actions within this module):

all:
    is_secure: on
    credentials: admin

I assume the ‘is_secure: on’ might be omitted, as the default is set to on. It somehow bothers me to see that it is not possible to include this in the application-level security file, covering all the modules actions at once.

Four important notes when you encounter problems:

• The names listed as the credentials are the names you’ve given to your permissions! Seems logical, but try not to change them to much, as you might break access to certain parts of your site.
• The permissions assigned to the groups are granted to the users, and the permissions listed below the users are added when checked.
• When you change your own credentials, make sure to log out and log in again!
• And finally, control the access to the plugins sfGuardUsers, sfGuardGroups, sfGuardPermissions the same way as other modules, by changing the security.yml files in the plugins/sfGuardPlugin/modules/…/config/security.yml files. Don’t change the access to the sfGuardAuth module, as it needs to be accessible by anyone to be able to login (see picture).

PHP Parse error: syntax error, unexpected ')', expecting T_PAAMAYIM_NEKUDOTAYIM in
/Users/bernard/Projects/someclient/somedir/somescript.php on line 100

Wtf?

Wat bleek, ik had een paragraafteken gezet ipv een dollarteken (vraag me niet waarom, ze zitten metersver uiteen op m’n keyboard).

Maar wat betekent die rimram nu? Blijkbaar is het hebreews (uitgeschreven in het engels natuurlijk), en betekent het iets als “dubbele punt” of “dubbelpunt”. Het is een gevolg van het feit dat de makers van PHP uit Israël afkomstig zijn.

We zien ook op de PHP list of parser tokens het volgende:

T_PAAMAYIM_NEKUDOTAYIM	::	::. Also defined as T_DOUBLE_COLON.