About to blow my top!!!

[TxsBmw]

I just upgraded from an old reseller account that I had been on since 2006 to one of WHB new reseller accounts so I could have MySql 5. WHAT A HUGE MISTAKE!!!! I should have said screw it and gone with another company!!!!

Here is my problem. I was switched to this new "better" server. Just to have my site on this new server for a few short hours before everything went haywire because of a power outage. Now that everything is back online my sites (I have 2 of them right now) load VERY slow or end up not loading at all. Of course WHB says it is nothing on their end that they can pull up everything just fine. So it must be my computer as well as all my members computers. Umm sure!

Anyway, I noticed that my home path in Cpanel is home2/username instead of home/username now I run vbulletin on both sites in which you have to put the path to your forums in the config file. Well on the old server it was home/username. I was told by WHB that it would not be causing the problem I am experiencing that I can use either home or home2. That seems odd to me. I also asked them to check my php.ini file which THEY created, just to be told that I must have entered a wrong file path in my php.ini file to Ioncube because it is throwing errors. Funny how they are the one that created it yet I am the one that is blamed. That however would not affect the second site as I do not have a php.ini file on that one.

All I want is for my site to work correctly again! Like it did before the move to this new "better" server. Also, I am on rssg3. The sites in question are http://www.usmchangout.com and http://www.militaryracingnetwork.com the major hang times are occurring in the forums part, and it don't happen immediately takes several clicks. Oh I might also add it happens when I try and access my cpanel as well

Anyone have any suggestions? Or what I can check?

[TxsBmw]

So they gave me a copy of my apache error log and it shows that my page is trying to load ioncube from an account that does not exist, error after error. I am assuming this is the problem. Yet in the very same reply that they post the log they tell me: "As we can see there are no problems with the server. We advise you to contact the developers of this cms".

REALLY!? You don't see all the errors!!!! And my "cms" is vbulletin (the same software they use here).

I would assume there is a quick easy fix of just fixing the path for ioncube.

The funny thing is I have not changed anything at all since the move. It worked fine on the old server and immediatly starts with problems on the new. But as always it is never "their servers".

So does anyone have any ideas because basically they just told me to F off that they aren't dealing with it anymore.

[Eugene B.]

Let me clarify the situation a bit. While moving from one server to another it is highly possible there could be minor breakdowns, which lead to necessity of website tuning. We don’t deny that it could be caused by specificity of server configuration, but it worth bearing in mind that there are “engine” peculiarities, which is used for the site.

Now, here are the details.
The peculiarities could be:
- php version set by default. For example on some of our servers php4 is set by default while there is php5 on the new ones. That’s why content of php.ini file differs, depending on exact version.
- modules supported by PHP. The modules could be changed/renamed/reincarnated/merged from version to version. We in our turn make sure that the features listed on our main site are present on the servers. The striking example is IonCube, I’ll draw a picture of this one below.
- MySQL version. On older servers we use MySQL4 and on the new ones MySQL5 is used.
- OS version (for example CentOS 4 and CentOS 5). Or there could absolutely different operating system installed, to say FreeBSD.

And with all this, we don’t forget that account transfer from old server to a newer one could take place (like in your case).
Website engine peculiarities. I think it will be enough if I list a couple of them:
- Using of full or relative paths while using with resources of the same website. Full paths could be used (if necessary and unavoidable), for example /home/userexample/public_html, and this is one of the first things user should reconfigure/recheck after transfer/account name change (the full path will be /home2/userexample/public_html now). After cPanel username change, the path will be changed as well from /home/userexample/public_html to /home/userexample2/public_html. And result would be website which is not working, and it is quite hard to blame server for this. If relative path were in use, there wouldn’t be such a need to change paths. In any event it is necessary to debug this. Or more exactly one shouldn’t forget about this.
- Redefining of php settings before using it. All we know that some engines require additional php settings. This can be done by means of php.ini or .htaccess file (everything depends on php mode) placed to the directory where the resource is located. And we provide such a possibility to our clients. Moreover, we doing our best to help in all possible ways if needed. And still, let’s examine one of wide-spread situations. Let us suppose, client’s account was moved from the server under control of Linux OS where PHP4 is in use to FreeBSD server with PHP5 installed. And client’s website contained php.ini files with special settings needed for his website to work. And at this very point the problem with IonCube frequently raises. The matter is that on the server with PHP the file ioncube_loader_lin_4.4.so loaded. And this very setting is specified in the php.ini file created for the website.
Now, when on the new server where in global server configuration correct module ioncube_loader_fre_5.2.so loads (using which everything is working correctly), the client’s php.ini file forced php wrapper to use ioncube_loader_lin_4.4.so which obviously doesn’t exist on the new server.

And for sure this is not problem/impairment/inconsistency of the server configuration. As by default all the settings of php wrapper were correct, before the moment php settings were redefined by configuration stated in user php.ini file.
Anyway, our team always tried to help clients with account transfer if this doesn’t require additional knowledge in programming field. We don’t aspire to say “F off” as you put this into words.We can keep checking your main website page till we drop and say that there is everything normal with it (and that happens this way quite often), and the error would be hiding on one of site pages, the page we of course know nothing, as you didn't tell us about this in your request. We just need to get as much constructive information from client as possible, which will give us possibility to understand what happening exactly with the website. Sometimes it is easier to list all actions (step-by-step) one needs to do in order to reproduce the issue than write many times that website is not working.

[TxsBmw]

Well I know nothing about php.ini files. WHB was the one that created them for me and configured them on the old server. In fact when they posted the error log and it showed that it Ioncube had a path to an account that no longer existed and then proceeded to tell me that no errors are being found. I was the one that had to point it out and say "well isn't that an error"? And WHB responses was basically oh sorry we will fix that.

So it is apparent that WHB is not looking into it at all. I am assuming it is something in the php.ini files on the main website. However the new website was just created right before the move (as in just an hour or two). I have checked all paths as far as /home/user/public_html and have changed any files that call for it (which there was only 1.

But when WHB sits there and tells me your site is pulling up fine on our end so it must be just your computer!!!! Thats not right especially when I know for a FACT it is not just MY computer!!!! So I pay them MORE money and get worse service!!!

[Alexey V.]

Bridget,

Please understand that we are neither web developers nor web designers who created your particular websites. When we stated that the sites were pulling up fine this meant that we had managed to access the home page of your websites and it had pulled up fine. However we did not investigate every single page and link on your website. Even if we did, it would have been hard to tell right away what exactly was wrong as we didn’t develop you websites and couldn’t know the exact way it was supposed to function. However we did find the error after you specified what exactly wasn’t working and didn’t deny it but rather went on to fix it.
The problems that occurred after the account transfer were caused by the following two reasons:
- you were using custom php.ini file with a full path to the library required by your scripts;
- accounts’ 'home' directories were changed after transfer;
cPanel uses an automatic transfer method which causes no problems in cases when scripts are not using full paths to files. Therefore if the paths were relative then there would have been no problems with the scripts after the change of 'home' directory.
Once again please accept our apologies for the inconveniences. The situation that happened was not triggered by us on purpose. This was a kind of issues that can and do occur due to the way the transfer is automated. With the help of your feedback we were able to fix it and now everything should be working fine on your website. If it is still not please give us more information regarding the current state and we will investigate this further until all server administration issues are fixed.

[TxsBmw]

I don't know where you can say it is fixed, because it is not. And the php.ini files were created by YOUR company not ME. You asked me to provide the exact steps to reproduce the problem. But instead of following those steps, you just pull up the home page and call it a day and tell me it must be on my end. So why even ASK for me to provide you with the steps if you don't even plan on taking them to reproduce the problem?

Actually I can tell you what the problem is. Its called poor management of employees and policies on WHB part. When you have 5 different people working on the same ticket who apparently don't even talk to each other about what is being done, then you have issues like this arise. I pointed out that the path in the php.ini files may be incorrect as they were pointing to an account that didn't even exist and it took a day and several technicians to figure that out and correct it.

Now I would like my sites to work correctly. If I would have known that switching servers would cause this kind of problem I would NOT have upgraded! And it would have been nice if your sales department would have let me know before hand.

[Anna M.]

Please check CFF-893987 and reply to it.

[TxsBmw]

I had already replied to it on the 20th. I think you are a little late Apparently it was the firewall on your server that was causing issues, it has been fixed since the night of the 19th.