Unfortunately, I have a massive problem after transferring my developer version to the production system. I cannot log in after the installation (error: “You do not have permission”). The production system is a shared host provider where I have successfully installed another backdrop domain. The previous domain of my faulty “new installation” was running Drupal 9, latest version. Here are the details of the installation attempts. On the production system, I first tried the same steps as with the successful installation:
1. create a new, empty SQL database
2. completely empty the /web folder on the server. Unfortunately, the folder /web/sites/default remains with its entries. These cannot be deleted with my authorizations. However, I can empty all contents.
3. copy all files from the development server to the production server, with the exception of the settings.php file
4. copy the settings.php file from the original backdrop version.
5. start the installation by calling up the site via the browser (with German language setting)
6. installation runs without errors. However, I am not automatically logged in as administrator.
7. attempt to log in with previously entered login data. Login fails with error message.
Next attempt:
- Emptying the SQL database
- completely empty the /web folder on the server (same result as above).
- Copy the original Backdrop installation files to the /web folder
- Carrying out the manual standard installation, language setting to German
- Same result as above
In the meantime, I have also sent a request to the provider to delete the remaining files in /web/sites/default. Does anyone have a suggestion on how to solve the problem of the faulty login? Is it necessary to delete Composer or Drush on the target system? Could there still be old, interfering data in the cache of the target system? How could this be deleted? Many thanks in advance.
Comments
If you can install Bee then there are commands that can reset passwords and provide a one-time login link:
https://github.com/backdrop-contrib/bee/wiki/Usage#users
I have already used the standard way to reset the password in the browser. After receiving the link by email, I used it to reset my password. However, I was still unable to log in afterwards. Is the variant using Bee different?
Well, using Bee, if the reset link doesn't work you can actually set the password of an account.
You can also clear caches with Bee
You might also want to try clearing the opcache in cPanel or other control panel if applicable.
If the
$sitesarray insites/sites.phpis empty then Backdrop should load ok.Thanks for the tip. I have now installed Bee, but will wait for feedback from the hoster before trying again.
Incidentally, I get an error message when I call up Bee:
PHP Warning: Failed loading Zend extension 'xdebug.so' (tried: /usr/lib/php/20190902/xdebug.so (/usr/lib/php/20190902/xdebug.so: cannot open shared object file: No such file or directory), /usr/lib/php/20190902/xdebug.so.so (/usr/lib/php/20190902/xdebug.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
As I have no possibility to install this extension on the shared host, I wonder whether this will lead to restrictions in use.
That's rather odd. There is xdebug in the lando recipe but that will only be invoked when using the Bee lando recipe for development and testing purposes; even then it has to be turned on.
I just tested with the latest version of bee on my shared hosting and I don't get that warning; I also don't have xdebug turned on there (though in theory I could as it is an option).
How did you install bee there?
I have installed it as described in the file Installation-on-shared-hosting.md:
Do you get the same error in the account on the same host with the working Backdrop domain?
I think it must be something about the particular host environment and what is installed that is triggering it. Perhaps your D9 had xdebug in the composer and that is interacting with it? I don't know and can't reproduce as there is nothing in Bee itself that calls xdebug.