migrating WordPress apps manually fails with lots of errors

I am finding it to be a challenge to migrate WordPress sites from another server. I am finding that, in general, migrating by hand seems to fail. Here’s roughly the steps I expect should work:

  1. Create a user/domain in ApisCP.
  2. Create a database in ApisCP.
  3. Transfer files from the old server to the new, in the new web root directory.
  4. Export/Import database from old server to the new.
  5. Update database parameters in wp-config.php.

Failures are various but include apache errors 404, 403, or 500. Even so, ApisCP can “Detect” that WordPress is installed at this point and even see which plugins it has. It’s just not delivering the app via apache to the web. One error I was able to identify:

[Wed Aug 21 23:23:23.042676 2024] [autoindex:error] [pid 3255:tid 3303] [remote xx.xx.xx.xx:59323] AH01276: Cannot serve directory /var/www/html/: No matching DirectoryIndex (index.html,index.php,index.fcgi) found, and server-generated directory index forbidden by Options directive

(despite index.php being present; and oddly this error fell into my main /var/log/httpd/error_log instead of /home/virtual/siten/fst/var/log/error_log.)
Another error I saw at one point is that if, after I transfer the files, I use the ApisCP web interface to modify .htaccess I get an error:

inconsistent status `500' returned, reverted control file /var/www/t.httpus.net/.htaccess

Anyway, what does work for me is to use ApisCP to install a fresh WordPress app first, then delete the contents of the web root directory and transfer the app as in the steps above. Apparently the ApisCP WordPress script is doing something that I am missing when I try to do it by hand.

What am I missing?

This is expected behavior. SSL is not configured for the domain. WordPress is forcing a SSL redirection. Per Apache matching rules, it falls through to the server-wide container, which serves documents out of /var/www/html instead of the vfs. Once SSL is setup on the account, it will serve documents for that domain within its vfs.

Check /home/virtual/siteXX/fst/var/log/httpd/error_log and possibly var/log/php-fpm.log within the vfs for further information.