Various problems after changing hosts

[GigaWatt]

So, any idea to help me?

It's getting worse, now I only have 2 topics showing  in each section...

Could you set up a free hosting account on a free host, run repair_settings.php on it and see if you get the same result? You don't have to upload the attachments in the attachment dir, just the .htaccess and index.php files.

Just to rule out server config, though, as drewactual said, this is the likely scenario at this point.

[epikurieu]

I bet the OP is using shared hosting and has no idea how the server is configured.

Indded, I said it in my first post. I am not an expert of hosting and servers, sorry... I did some research and if I understood right, PHP flavors are used in cloud hosting, right? Mine is not a cloud hosting, it's a shared server in a physical datacenter, as I understand it. So I don't know if all this applies in my situation...

Anyway, I tried to set up another copy of the forum on an old free hosting I have, but I get a 500 error which I don't know how to solve, and I'm getting a bit downhearted here.

And what if the hypothesis were right and it were because of the server config? What would the solution be? Fresh install? I might as well do it right away, shouldn't I?

[Sir Osis of Liver]

The easiest solution - a clean set of files. You'll loose all of your mods, but you can install them again afterwards .

^ Do this, you're not going to fix it any other way.

[GigaWatt]

And what if the hypothesis were right and it were because of the server config? What would the solution be? Fresh install? I might as well do it right away, shouldn't I?

Do a fresh install, create some boards, also create some users, post some topics, etc., and see if the problems are fixed. If everything seems OK, delete everything (the test install) and do what I posted previously (what Sir Osis of Liver quoted ).

[drewactual]

the 'flavor' i speak of is how apache is configured- and is dependent on how the hosting company arranged it.   many of the functions can coexist on a configuration, but others can't- they conflict- and because of which hosts will eliminate one or the other.  HERE is a brief discussion with links available to further understand, if it is something you find interesting: https://www.howtoforge.com/community/threads/help-choosing-php-mode-php-fpm-suphp-mod-php-fast-cgi.63893/

a server error log should demonstrate the fault as 'requested file by user ---- denied by server configuration' or something to that impact...

IF it worked on one server but not another, and that fault is present and obviously permissions based, then it's most likely what i suggest... FPM-PHP is controlled at the domain level, which means your server manager can recover it for you, where as FastCGI and, say, SuPHP CANNOT run together, and is handled at the server level.   

spelling it out for you, if you were to ask your host:
- to see the error logs or ask if the error's present are permissions based where either 'anonymous' or 'user' is being denied
- to either turn FPM on or off for your domain depending on the above question
- if running FastCGI to run FPM alongside it; if running SuPHP to run mod_fcgi and w/ anonymous allowed as user in the php.ini file (SuPHP doesn't allow 'downwind' .ini files or htaccess files for domains). 

I feel for you, Sir- digging around in server configs or hoping your host has enough interest to focus on a single client to smooth the running after a move is a real PITA, and it's often difficult to find hard cold answers. 

[epikurieu]

So I tried to find some information, here is what I gathered:

   
• I can choose between FPM on and off
• as I understand it, if FPM is on, FastCGI is off
• these options are handled in a config file, I'll attache a file with details

I can choose between several environments: https://docs.ovh.com/fr/hosting/modifier-lenvironnement-dexecution-de-mon-hebergement-web/#decouvrir-les-configurations-disponibles (sorry it's in French, but I think you can understand the chart)

So I tried various combinations, none of which seemed to do any good.

As for the erros logs, I only have some for two days since the migration, I'll attach the files too. As for yesterday's, it seems the only errors where caused when I tried to change to PHP 7 to see if PHP errors where shown on the pages. Well, the result is nothing worked at all! 

But I also ran into something just now, when I tried to see the unread replies to my posts (https://www.neuronesconnection.fr/unreadreplies/). There's an error here:

MySQL server has gone away
Fichier: /home/mapyo/neuronesconnection/Sources/Recent.php
Ligne: 1084

Note : Il est possible que votre base de données nécessite une mise à jour. Actuellement, la version des fichiers du forum est SMF 2.0.15, alors que votre base de données est en version SMF 2.0.4. L'erreur signalée ci-dessus pourrait peut-être corrigée en exécutant la dernière version de upgrade.php.

The note says that my database may need to be upgraded, files version is 2.0.15 while database version is 2.04, the error might be fixed by running the latest version of upgrade.php

[drewactual]

nah, that error is almost an error unto itself (the one about upgrading db's).. i don't think it has changed for 2.0+....

give me a bit to look at your uploads.



so.... if i'm looking at those logs along with that config file with straight eyes, your server is looking for php7 and not finding it, and falling back to fastcgi... then, in the error log and after deciding NOT to take into account fastcgi (as it is the fallback) errors, it looks for php7 in "/var/lib/fastcgi/php//images/squeeze.i386/7"

now look closely at that location address and tell me what's wrong with it?

rattle your hosts cage and tell them to repair their httpd file under their shared (virtualhost) settings to look for php in the right place.... it's usually in an apache directive... i can't imagine why it wouldn't be... and tell them to pay better attention to something so silly! 

also, just for the sake of senility, have them change the ini/httpd to look for headers in the right place, or tell it not to altogether.  it's a 'switch' iirc (an on/off, 1/0 setting).... IF headers are selected, there is a following directive to choose which type and flavor of headers to be sent.

hope this helps.

[drewactual]

just so you see the 'new' icon i'm posting this... response above in edited post

[Sir Osis of Liver]

The official mantra is there were no database changes in 2.0 branch, but iirc there was a minor change around 2.0.6, something to do with attachment mime types, but it wouldn't be causing the problems described here.  The database version error is usually bogus.

[drewactual]

And to spell "silly" out, as kindred has a valid point:  the notes in a virgin httpd file spells out "without the trailing slash" and the other for specific domain says "with leading slash" so folks don't mess this up. 

And the location itself is..... Different... But who knows about that. 

There is also a mod for apache that allows apache to find something even if the address is wrong so long as it's only slightly wrong... For instance, if someone had two slashes leading in a hard coded address php can ignore one of them and look for the file w/o it... If no file is found in the directory by that name it will look in the parent directory... It can, from there, be configured to look up, across, or down in other directories for files with similar names..... It will execute the file it thinks you are looking for.... This is a great thing in some cases, but really bad in others.

For some reason I'm thinking this mod likely exists on ypur server, and it has decided to look in the directory listed in the error... Why? Because I can't imagine a server being set up with php in that location.  It makes no sense, and it kinda flies in the face of "better practices"...

[epikurieu]

If I understand correctly (we really are reaching the limits of my knowledge here) you see a problem in the configuration of PHP7? Unfortunately I don't think we should focus on that, since I only enabled it for a few minutes and then turned it off. The actual PHP version is 5.4.
There are no other error logs, even though I know that there was some traffic on the forum.

Are the error log for 27/10 and the config file of any help?

[drewactual]

Will look at it again, but....

In the httpd file under virtual host there is a trailing slash telling apache where to find pip... It likely doesnt matter which php you choose that trailing slash will be there, and just as likely to be causing issues. 

[epikurieu]

OK I'm not really sur I can get the host to do anything about it, because half of the time you are in relation with sales people who know less than me about technical stuff, and the other half I'm afraid that I'll run into someone who won't bother to listen to what a simple client might have spotted...

[drewactual]

the older error log chorus's "FastCGI failure fallback to CGI" which basically informs me that php IS NOT being implemented. 

I recall having issues with FastCGI and encountering this precise issue, and it boiled down to php not being implemented/started at all, but i don't recall what i did to recover it...

so..... if this were me, and it isn't, but if it were- i'd select FPM without FastCGI as a backup (which falls back to cgi and what is evidenced in your error log).  Then, I'd make certain the httpd is looking in the correct place, and the call DIDN'T have double slashes. 

the header issue stated in the log you provided (10/27) is a giveaway in-that "without header, how does the server know how to send or the browser how to display?"- in the httpd or .ini file there is a line addressing how, when, and what (if any) headers are provided.  the config, according to the error log, is obviously looking for headers and isn't finding them.


in short, your configuration is wrong- and is something you can't access most likely. 

if i were you i'd find another host.  setting up a server for php engined websites ought to be child's play for anyone in that industry, and they are falling on their faces it appears...... and, it won't matter if you load a new SMF or any other php operated engine, as it will fall on it's face too....

[drewactual]

do this:

make a new file, call it "info.php" and make this the contents of the file:

Code Select Expand

<?php
phpinfo();
?>

then...navigate on your browser to that file, and tell us when it's live so we can see it.  I wager php is not initialized and if it is it is not configured properly.

[epikurieu]

https://www.neuronesconnection.fr/info.php

It seems that there's no double slash problem for version 5.4, is there?

I've been working with this host for years, we built a lot of PHP based websites (I work with a programmer, but he doesn't use frameworks or web-based software, that's why I don't ask him about this problem) and it always went OK, so I'm confused...

[drewactual]

5.4 looks to be okay- does it function as you expect?

5.4 is also not a part of apache4.x iirc- which means apache has been rebuilt on the server? <- scratch that, the build date says 24 Sept 2018 @ 07:57:52....

when you were attempting 5.6/7.0, how were you going about that?  this may explain why the config was looking in an image file for 7.0?

if 5.6/7.0 is available on the server, and it is a standard build Apache 2.4, the config file should be looking in the ...../usr/local/ea4/php5.6 (or a similar structure) directory akin to where it's finding 5.4 (which is /usr/local/php5.4/ect).... if you want 5.6+ (i think 2.0.15SMF will work on 5.4, just not recommended) the host simply needs to build and deploy apache2.4 and allow 5.6, 7.0,7.0x,and 7.1- and preferably in a pre-fork or FPM flavor.  those two seem to work the best for the nature of forums.  as a result of this build, they will need to change the httpd and have it pointed to the correct location of php (which it should fresh out of the box).

seeing that 5.4 is available and has been since September on this server tells me that MOST LIKELY 5.6 and 7.0 was NEVER TRULY available, as it creates a conflict.  It also offers some insight as to why it was looking for ea2.4 in an image directory... when i say image don't think picture, think more akin to clone.

[drewactual]

oh- and to the question about the earlier error log: FastCGI has to be told where to find php, it doesn't do it out of the box.  hence the FASTCgi error's resorting to CGI... and likely because php never even started to begin with.

also- i had trouble getting IonCube10 working with FPM and FastCGI.... IonCube5 worked, but the updated (10) would NOT play nice and crashed apache.  Once i removed it altogether (disabling it didn't work) upon Apache rebuild, all was well.... but this has nothing to do with your issue, but it will be good to know if you upgrade to ea4/php5.6+...

[epikurieu]

I didn't understand everything you said in the two last posts, but anyway I found the origin of the problem and corrected it. I'm embarrassed to say it, but it was a bad database export (or more likely, import) that caused all that...

So thanks to all of you for your help.