XF 2.1 Bizarre or Not? Config is still using old database

John917

Active member
So I duplicated the forum directories and files to a new website (hosted locally on the same server) and changed the /src/config.php with the new database (which was duplicated too).

Anyways, so I'm thinking they are now independent from each other, but the duplicated forum is STILL using the old database. I deleted the duplicated database to be sure and low and behold it's still using the old database.

Is there something I'm overlooking? This is the first time duplicating locally on the same server so maybe that's why? I doubt it since the database config not registering seems to be the issue here.

Any help is appreciated... so bizarre... I guess...
 
Ok now I get open_basedir errors. Any thoughts?


  • [E_WARNING] file_exists(): open_basedir restriction in effect. File(/home/admin/web/originalsite.com/public_html/src/addons/vw/vw/_core/controller/ui/edit/attach/xf2.php) is not within the allowed path(s): (/home/admin/web/newsite.com/public_html:/home/admin/tmp)
  • src/addons/vw/vw/_hard/core.php:748
 
As far as someone more experienced answers you, can you make a replica of the database with a different name?

Let's suppose that your database is called DB_01, you make a backup of BD_01, you create a database named BD_02.
And then you restore the backup of BD_01 to BD_02 database, and don't forget to rename the corresponding line of config.php:

$config['db']['dbname'] = 'BD_02';
 
If the config file was updated then there's no way the installation can be using the wrong database.

As both installations are on the same server, you do need to be mindful of caching and cookies.

This guide covers that.


The open_basedir issue is due to server configuration.
Your host will be able to resolve it.
 
If the config file was updated then there's no way the installation can be using the wrong database.

As both installations are on the same server, you do need to be mindful of caching and cookies.

This guide covers that.


The open_basedir issue is due to server configuration.
Your host will be able to resolve it.
For the open_basedir is there anything else I can try other than disabling it on php.ini? Tried disabling with no success.
 
According to the official php website https://www.php.net/manual/es/ini.core.php#ini.open-basedir your error may be related to some php script making calls to files outside the directory tree.

If you have two installations of your forum, make sure they are on different domains or sub-domains, and if they are on different sub-folders within the same domain or sub-domain, make sure each config.php file has a different cookie prefix on each installation, the directive is

$config['cookie']['prefix'] = 'XF2_';
 
If you have access to your php.ini file, you can put open_basedir = /

Although this poses a security risk, doing it provisionally would help you see if those errors disappear.

It all depends on whether you have full control over php.ini or not. In shared hosting, that parameter is defined by the provider.


XF's default configuration does not call any files outside the webroot, but if the administrator activates for example the option in the administration panel, Setup > Options > Attachments: "Imagemagick PECL extension", then it will be necessary to authorize in php.ini access to the path where the Imagemagick application is installed, usually /usr/bin


The same happens if some add-ons call a route outside the webroot need access to /tmp, a system directory outside the webroot.


Ok now I get open_basedir errors. Any thoughts?


  • [E_WARNING] file_exists(): open_basedir restriction in effect. File(/home/admin/web/originalsite.com/public_html/src/addons/vw/vw/_core/controller/ui/edit/attach/xf2.php) is not within the allowed path(s): (/home/admin/web/newsite.com/public_html:/home/admin/tmp)
  • src/addons/vw/vw/_hard/core.php:748

In your case it is an add-on that is trying to access an external path to your webroot, the add-on installed in the "src/addons/vw/" folder, check its configuration, and if you cannot give it the necessary permissions, you will have to deactivate it.
 
No to your statement that I quoted ;)

XenForo does work just fine with open_basedir and ImageMagick; it is not necessary to adjust the open_basedir setting to include ImageMagick binary paths as those are not being used anyway.
 
No to your statement that I quoted ;)

XenForo does work just fine with open_basedir and ImageMagick; it is not necessary to adjust the open_basedir setting to include ImageMagick binary paths as those are not being used anyway.
Some time ago, the following happened to me: many users of my forum wanted to use motion animated gifs avatars, but motion was not applied, only static images.

I solved that by activating the option you mentioned in the control panel, and that you quote, but it was not enough. In my case I don't have a shared hosting, but a dedicated server, with GNU/LINUX Debian as operating system. That allowed me to add by myself the path /usr/bin to the open_basedir parameter of the php.ini file (until I did that it didn't work).

Each operating system and web server is different and has its own particularities. In the case of shared hosting, some have Imagemagick enabled by default, and others do not. In the first case the forum administrator does not have to do anything, in the second case he has to ask the provider for access to Imagemagick's path. That is obejetively so, it does not depend on my opinion or yours, mate. It doesn't depend on Xenforo either, this wonderful sotfwara works very well with the Imagemagick option activated, if the hosting provider enables that access (a general or particular php.ini pass for a given client), otherwise, no.

P.S.: Binary paths to ImageMagick can be direct or a symbolic link, but without them the option doesn't work, at least in my case.

Translated with online Translator, texto original en español:
Hace ya un tiempo me ocurrió lo siguiente: muchos usuarios de mi foro querian usar avatares de gifs animados con movimiento, pero el movimiento no se aplicaba, solo imagenes estáticas.

Solucioné eso activando la opcion me menciono del panel de control, y que uste cita, pero no fue suficiente. En mi caso no tengo un hosting compartido, sino un servidor dedicado, con GNU/ LINUX Debian como sistema operativo. Eso me permitió añadir por mi mismo añadir la ruta /usr/bin al parametro open_basedir del archivo php.ini (hasta que no hice eso no me funcionó).

Cada sistema operativo y cada servidor web son distintos y tienen sus propias particularidades. En el caso de los hostings compartidos, unos tiene habilitada por defecto el uso de Imagemagick, y otro no. En el primer caso el administrador del foro no tiene que hacer nada, en el segundo caso tiene que solicitar al proveedor acceso a la ruta de Imagemagick. Eso es obejetivamente así, no depende de mi opinion ni de la suya, compañero. Tampoco depende de Xenforo, este maravilloso sotfwara funcionará muy bien con la opcion de Imagemagick activada, si el proveedor del hosting habilita ese acceso (a traves del php.ini general o particular para un determinado cliente), si no, no.

Posdata: las rutas binarias a ImageMagick pueden ser directas o un enlace simbolico, pero sin ellas no funciona la opcion, al menos en mi caso.
 
Last edited:
Each operating system and web server is different and has its own particularities. In the case of shared hosting, some have Imagemagick enabled by default, and others do not. In the first case the forum administrator does not have to do anything, in the second case he has to ask the provider for access to Imagemagick's path.
XenForo 2 does not use any ImageMagick binaries (convert, mogrify, identify, etc.) which would indeed be located in /usr/bin on a Debian system.

In fact we don't even have the binaries (imagemagick-6.q16) installed.
 
XenForo 2 does not use any ImageMagick binaries (convert, mogrify, identify, etc.) which would indeed be located in /usr/bin on a Debian system.

In fact we don't even have the binaries (imagemagick-6.q16) installed.

Since I'm very curious and like to get to the bottom of these technical issues, I'm going to try restricting php access to my forum's root web, for example open_basedir = /var/www/html

Let's see if I can still see the movement of the animated avatars, and then I'll comment.
 
Edit: I just made the test, and you can see the movement of the animated avatars, even disabling them in XF Imagemagick.

KnExaDO.png


About two years ago, running XenForo version 2.0.x, the animated avatars didn't work if the Imagemagick extension was not activated in the XF configuration. Today, the animated avatars show their movement with the GD libraries.

php has evolved and XenForo has evolved, you no longer need Imagemagick for certain things, for example to show animated avatars.

That doesn't prove, however, that XenForo can use the Imagemagick extension without php having access to its binaries.
php needs to have the module enabled and access to its binaries, that's right.
 
Last edited:
About two years ago, running XenForo version 2.0.x, the animated avatars didn't work if the Imagemagick extension was not activated in the XF configuration. Today, the animated avatars show their movement with the GD libraries.
For displaying avatars it doesn't matter which image processing library you are using, if you have existing animated avatars they will be displayed no matter which library is selected.
But you still would not be able to upload new animated GIFs and have them thumbnailed with GD, this does require ImageMagick.

This does not prove, however, that XenForo can use the Imagemagick extension without having access to its binaries.
Correct :)
 
Top Bottom