Adapting WordPress to a legacy web site’s user authentication system?

by philg

Folks:

We’re celebrating (feebly) the 23rd anniversary of philip.greenspun.com. The site currently runs software that is nearly 20 years old, the ArsDigita Community System version 3.3 (docs). Although it pains me to admit this, it seems that there have been some improvements in web toolkits, especially for authoring without Emacs proficiency, since the mid-1990s.

I’m not quite ready to throw out everything that we built in the 1990s but for new content it would make life easier if I could author, and users could comment, via WordPress.

Has anyone tried bolting WordPress to a legacy web site that already has a username/password authentication system? I would also want people to be able to authenticate using Facebook. Any tips on how best to integrate WordPress with a legacy online community? It would not be acceptable to break any existing URLs. And I really don’t want to exert any manual effort to bring old hand-authored HTML into WordPress.

Thanks in advance for any advice.

6 thoughts on “Adapting WordPress to a legacy web site’s user authentication system?”

  1. I recently updated my site to using WordPress. Some random notes:

    Basic install was painless (my host already had MySQL installed, which helped).

    I haven’t worried much about user authentication yet (readership is still in double digits…)

    I was able to move some legacy pages into it with straightforward cut ‘n paste. For more esoteric cases, pasting/editing HTML into the “text” view usually worked reasonably well.

    I wound up creating special pages to package up links to legacy content. Some hacked python scripts helped set these up.

    By far the biggest time sink for me has been hacking/tweaking the template. Most of the free templates are terrible, unless you like huge irrelevant graphics. The “Commune” one supplied wasn’t bad, but still took considerable hacking to get graphics in SVG working, and to provide acceptable output on mobile devices. The default WordPress install is oblivious to the existence of mobile devices.

    CSS is arcane, and you’ll learn more than you want to know if you want to tweak the layout. I now understand why consultants charge $N,000 to set up a WordPress blog.

  2. Getting WP to talk to an existing authentication system is painful. I have done it. I’m afraid I don’t remember any tips.

    There are plugins to allow Facebook auth so that should be painless.

    To keep all your old stuff you’ll setup your WP install in a new subdirectory and leave everything else as-is. WP won’t know about your existing pages or photos (“Media” in WP terms). It won’t do anything to your old content.

    If you create a page in WP you won’t be able to drag/drop your old photos in. WP won’t know about any existing photos (“Media” in WP terms). WP will only know about photos you upload into WP. But you can edit HTML and put any old in there so this isn’t a big deal.

  5. I have a fair amount of experience going the other way, as my company’s original user database was originally in WP (because we were too lazy to build a full user management system in our MVP, including pesky details like password recovery). We’ve moved off since, but I know a lot more than I care to admit about single-sign-on with WordPress.

    We long ago moved off to our PostgreSQL-based system with proper enterprise role-based access control, multiple users per account, two-factor authentication and argon2 password hashing, while still allowing authorized users access to WordPress authoring and admin tools.

    I have Python code that will generate WordPress authentication cookies, and other Python code that implements the crackpot PHPass password-hashing algorithm WP uses. Combined with some sort of replication or sync to send account info (with bogus password hashes) into WP’s wp_users table, you can have a minimally invasive integration where full WP functionality is available but authentication is handled by an entirely separate system.

    I will echo other commenters’ warnings. WordPress is a surprisingly poorly documented system considering its age and prevalence, PHP is a terrible programming language and doing even simple things takes an inordinate amount of time. The security concerns are also real. If at all possible, run WP and MySQL/MariaDB in their own container, isolated from the web server and your actual password database (easy to do with nginx and FastCGI, harder on Apache with mod_php).

    Unfortunately the open-source CMS space is rife with equally lousy PHP-based systems like the abominable Joomla. I don’t know if the NodeJS-based Ghopst is any better, but Node has its own API instability issues.

Comments are closed.