Installing arpReach

Installing arpReach
I have just gotten around to installing the new arpReach for myself; although it’s been out for about 9 months, I’ve only installed it for clients. This was a fresh install; I still need to upgrade some installations from ARP3 and the time involved in doing that is the main reason I’ve put this off.

arpReach is the successor to Autoresponse Plus 3, which I’ve been using for 6+ years. At first glance arpReach is a major improvement, but I’ll get to that in a later post. Maybe. Right now I just wanted to list some things I’ve found while installing it for myself and for my customers:

  • The installer checks if register_globals is Off. This is a good thing. However, for users with web hosts that leave this setting On, they will need to place a register_globals = Off entry in their php.ini file (and create this file if necessary). Since php.ini isn’t inherited by subdirectories and the installer check is from the ‘install’ directory, users (and even many script installers) will be confused when they’ve updated a php.ini file in the arpReach directory and the installer check still fails. Put the entry in a php.ini file in both the arpReach directory and the installer directory.

  • The installer asks for the database settings when it’s already checked for the presence of config.php and can use the settings from that file. I’m not sure why the user has to supply these again.

  • Clicking ‘Next’ deletes all existing data in the database.” — Here’s a scary message on step 5 of the installation. It’s also false. Any existing data in tables using the “arpr_” prefix will be deleted, but not all existing data. So if you’re using a single database for more than one purpose, only any pre-existing arpReach (not ARP3) data will be deleted.

  • Existing ARP3 autoresponders (if you’re upgrading) will now have an “arp3_” prefix — I don’t know why this is necessary. You may want to go back and rename those.

  • RSS feeds are enabled after the upgrade, even if your ARP3 autoresponders had this off. You’ll need to check those and disable RSS if you don’t want it enabled.

  • Banned email addresses and domains are not carried over on an upgrade. You’ll need to recreate those.

And updating from ARP3 is frustrating! Why can’t arpReach progress through each step automatically instead of requiring the user to do them manually? And if manually, why not mark each step as done when complete — and disable the “Start Import” button?

One last thing that may be confusing: when setting up the cron job for the arpReach scheduled task you probably will have to change the recommended command. Here’s what the installation PDF and user guide suggest:

php /path/to/public_html/<dir>/a.php cli/auto>/dev/null 2>&1

The online support article points out that the space between “a.php” and “cli” is intentional. What’s not clear is that you may need to properly refer to the PHP command line interpreter like this:

php-cli /path/to/public_html/<dir>/a.php cli/auto>/dev/null 2>&1

And until you get this command right, you may want to not suppress the cron output:

php-cli /path/to/public_html/<dir>/a.php cli/auto

The cron output will now be emailed to you at the address you specify in your control panel.