Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Strangest problem with WordPress... Any experts here?
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Strangest problem with WordPress... Any experts here?

JonchunJonchun Member
edited April 2017 in Help

I've migrated a website from GoDaddy to a personal cPanel server for a friend.

Here is what's strange:

  • The website works fine on GoDaddy

The site uses Visual Composer. The part I'm having trouble with is Visual Composer's "single image" feature:
https://wordpress.stackexchange.com/questions/221333/working-with-visual-composer-vc-single-image

Whenever I add a custom size such as "300x300", it freaks out and the image does not display. Here is what the HTML source ends up as:

If I use preset sizes such as "thumbnail", "medium", or "large", it works fine. It ONLY bugs out like this when I use custom sizes like "200x100".

Things I've tried:

  • Taking a cpanel backup from godaddy and importing directly into my cpanel server. This works. However, changing the cPanel username results in the problem stated above. I need to change the cPanel username in this case so keeping the old username is not an option.

  • Creating a fresh WP install and using a wordpress migration plugin. This again, results in the same problem about.

  • Creating a fresh WP install and installing Visual Composer on my cPanel server. Used the same theme as the site I'm trying to migrate. It works fine even with custom sizes such as "300x300".

  • Testing Visual Composer on a different site on the same cPanel server. It works fine even with custom sizes such as "300x300".

  • Exporting via PHPMyAdmin on GoDaddy, Importing via PHPMyAdmin on my cPanel server, moving the entire public_html contents over, editing wp-config to reflect the new db details. It bugs out like this when I use custom sizes like "200x100".

  • Tried changing PHP versions. Doesn't make a difference. Works fine on GoDaddy, does not work on my server.

  • WP Debug does not give any relevant information. It doesn't seem to be a PHP issue.

My conclusion: Something is whacky with the database. Since it works on a fresh WP install and a different WP install, I doubt there's anything wrong with the server itself. Somehow, it works on the GoDaddy server.... And it works if I do a full cpanel move and don't change the username. Any thoughts on why this would be happening?

I understand that help isn't free. Any WP experts feel free to PM me with your rates. However, this will be a "paid for completion" job and not a "paid for time spent" job, so be confident ;)

Comments

  • HarambeHarambe Member, Host Rep

    Initial thought leads me to believe you're missing a php extension like imagick, or whatever handles the thumbnail generation. So the only available options are the default sizes that were generated on the previous install when the image got uploaded?

    Might be off, but that's what I'd look at first. Make sure you've got all appropriate extensions enabled for the cPanel account.

    Thanked by 1WSS
  • @Harambe said:
    Initial thought leads me to believe you're missing a php extension like imagick, or whatever handles the thumbnail generation. So the only available options are the default sizes that were generated on the previous install when the image got uploaded?

    Might be off, but that's what I'd look at first. Make sure you've got all appropriate extensions enabled for the cPanel account.

    I covered that too. I phpinfo'd the GoDaddy servers and made sure all extensions are there. Please note that it's likely not an extension issue as the same shortcode works on OTHER wordpress installs on the cPanel server. If it were an extension issue, it wouldn't work on the other wordpress installs either?

  • HarambeHarambe Member, Host Rep

    @Jonchun said:
    If it were an extension issue, it wouldn't work on the other wordpress installs either?

    I was talking about the extension selector within each account. If they're hosted in the same account, then yeah it's not the issue. I've just seen a lot of shared hosting services with important extensions not enabled in an account by default.

    I don't know much about visual composer, so I'll leave it to a pro to help you fix.

  • You're right, the issue's with the database.

  • if both are cpanel based servers, then you need to replace the old username with the new one in the database. That should fix it.

  • @varunchopra said:
    You're right, the issue's with the database.

    Thanks?

    @Junkless said:
    if both are cpanel based servers, then you need to replace the old username with the new one in the database. That should fix it.

    I've already done that. I replaced all instances of the old username with the new one before importing via SQL. That is not the problem.

  • Just wondering if it could be an encoding issue? Wordpress now uses utf8mb4 encoding when available (mysql 5.5.3+) . I've seen issues where a site has been migrated from a server running new mysql to a server running old mysql, where utf8mb4 encoded data is pushed into utf8 format, causing all sorts of weirdness. WP Migrate Db https://wordpress.org/plugins/wp-migrate-db/ has a legacy export mode that can help gettinf utf8mb4 data back to utf8.

    https://make.wordpress.org/core/2015/04/02/the-utf8mb4-upgrade/

  • @squibs said:
    Just wondering if it could be an encoding issue? Wordpress now uses utf8mb4 encoding when available (mysql 5.5.3+) . I've seen issues where a site has been migrated from a server running new mysql to a server running old mysql, where utf8mb4 encoded data is pushed into utf8 format, causing all sorts of weirdness. WP Migrate Db https://wordpress.org/plugins/wp-migrate-db/ has a legacy export mode that can help gettinf utf8mb4 data back to utf8.

    https://make.wordpress.org/core/2015/04/02/the-utf8mb4-upgrade/

    The current cPanel server is using MySQL 5.6.35

  • WSSWSS Member

    The fact that it's crapping itself only with manual resizes tells me that the process running for that is receiving invalid data. The fact that it shits out src=(unknown) and height/width with no parameters- even wrong ones- is curious. I wonder if perhaps it automatically generates the predefined sizes, and for manual resizing uses a temporary directory under the docroot.. but really you should be looking into the resize function itself.

  • JonchunJonchun Member
    edited April 2017

    @WSS said:
    The fact that it's crapping itself only with manual resizes tells me that the process running for that is receiving invalid data. The fact that it shits out src=(unknown) and height/width with no parameters- even wrong ones- is curious. I wonder if perhaps it automatically generates the predefined sizes, and for manual resizing uses a temporary directory under the docroot.. but really you should be looking into the resize function itself.

    The problem is... Why would it only provide that output on this particular WordPress install? (Seems to be related to something in the database). It works perfectly fine on another WP site or on a clean WP install.

    Here's the code for the shortcode:
    https://pastebin.com/fT31TF7v

    I just checked in firefox and it shows:
    <img class="vc_single_image-img " src="" alt="cabbagemoney" title="cabbagemoney" width="" height="">

    So I'm not sure if the (unknown) stuff is something chrome does.

  • WSSWSS Member

    @Jonchun said:
    The problem is... Why would it only provide that output on this particular WordPress install? (Seems to be related to something in the database). It works perfectly fine on another WP site or on a clean WP install.

    Because it's broken. I don't really want to delve into a product I have no use for, but it's returning null/invalid data. It could very well be a stupid with the database query- I don't know- I haven't seen the code. Something in that custom resize routine is failing. Returning no data is a very WordPress/ShittySQL thing to do. The fact that it only does this with custom sizes is very telling where the issue lies, but not WHAT the issue is.

    Hit up their KB, and then open a ticket.

  • @WSS said:

    @Jonchun said:
    The problem is... Why would it only provide that output on this particular WordPress install? (Seems to be related to something in the database). It works perfectly fine on another WP site or on a clean WP install.

    Because it's broken. I don't really want to delve into a product I have no use for, but it's returning null/invalid data. It could very well be a stupid with the database query- I don't know- I haven't seen the code. Something in that custom resize routine is failing. Returning no data is a very WordPress/ShittySQL thing to do. The fact that it only does this with custom sizes is very telling where the issue lies, but not WHAT the issue is.

    Hit up their KB, and then open a ticket.

    I think we know that something is broken... That's the point of the thread. Brainstorming ideas on WHY it's broken.

    The fact that it only does this with custom sizes is very telling where the issue lies

    It's still curious that it works properly with a full cPanel backup+restore, but if you change the cPanel username or if you try to migrate the wordpress site using manual methods such as a DB backup + Home directory backup, it stops working.

  • If you really want to know you need to compare the two side by side. Look at the code and see if there is a difference. Check both databases the same way. Could be something as stupid as an apostrophe in the wrong place. Something changes during the transfer and the only way to find it, is to compare before and after.

    I know it will be tedious, but you will have your answer.

  • @AuroraZ said:
    If you really want to know you need to compare the two side by side. Look at the code and see if there is a difference. Check both databases the same way. Could be something as stupid as an apostrophe in the wrong place. Something changes during the transfer and the only way to find it, is to compare before and after.

    I know it will be tedious, but you will have your answer.

    It works fine with a cPanel restore. It breaks if I change the cPanel username. The files are exactly the same as changing a cPanel username will not modify the files.

  • Did you check to make sure it changed the owner info as well?

  • WSSWSS Member

    @Jonchun said:
    I think we know that something is broken... That's the point of the thread. Brainstorming ideas on WHY it's broken.

    You've been offered several suggestions to dig into this to try to find a solution, but so far have offered virtually nothing in the way of trying to resolve your issue beyond "it works until I change names". If you've found a way to make it work- then just leave the migration/names the same, unless there's some reason why you can't do so.

    It's still curious that it works properly with a full cPanel backup+restore, but if you change the cPanel username or if you try to migrate the wordpress site using manual methods such as a DB backup + Home directory backup, it stops working.

    Who knows how the licensing/et al works internally- the author, that's who! Your best bet is likely contacting the authors and asking whats going on with it, or just leaving the migrated data alone as it functions- and setting up a testbed to further resolve this issue.

  • @WSS said:

    @Jonchun said:
    I think we know that something is broken... That's the point of the thread. Brainstorming ideas on WHY it's broken.

    You've been offered several suggestions to dig into this to try to find a solution, but so far have offered virtually nothing in the way of trying to resolve your issue beyond "it works until I change names".

    No suggestions have been offered so far... What are you talking about?

    If you've found a way to make it work- then just leave the migration/names the same, unless there's some reason why you can't do so.

    You clearly didn't read the first post.

    It's still curious that it works properly with a full cPanel backup+restore, but if you change the cPanel username or if you try to migrate the wordpress site using manual methods such as a DB backup + Home directory backup, it stops working.

    Who knows how the licensing/et al works internally- the author, that's who! Your best bet is likely contacting the authors and asking whats going on with it, or just leaving the migrated data alone as it functions- and setting up a testbed to further resolve this issue.

    This is a prepackaged plugin that came with a theme. There is no license key. I've already contacted them via Slack and am awaiting a response.

  • saf31saf31 Member

    Just a suggestion... can you try wpclone plugin ? This one helped me in numerous occasions. I guess the godaddy site is still available.
    https://wordpress.org/plugins/wp-clone-by-wp-academy/

  • Jonchun said: It works fine with a cPanel restore. It breaks if I change the cPanel username. The files are exactly the same as changing a cPanel username will not modify the files.

    But it would change the linux path right? Probably that o.o

    Thanked by 1TheLinuxBug
  • @saf31 said:
    Just a suggestion... can you try wpclone plugin ? This one helped me in numerous occasions. I guess the godaddy site is still available.
    https://wordpress.org/plugins/wp-clone-by-wp-academy/

    Tried it.

    Creating a fresh WP install and using a wordpress migration plugin. This again, results in the same problem about.

    @sdglhm said:

    Jonchun said: It works fine with a cPanel restore. It breaks if I change the cPanel username. The files are exactly the same as changing a cPanel username will not modify the files.

    But it would change the linux path right? Probably that o.o

    Yes... but I don't see how this is relevant? I thought maybe somethign was hardcoded but there is no indication of the old username anywhere in the database or in the files.

  • If it's caused by database, then use
    https://interconnectit.com/products/search-and-replace-for-wordpress-databases/
    Remember to replace the absolute path.

  • TWoTWo Member

    We all can only assume. Why don't you just contact their support as already suggested by WSS.

  • JonchunJonchun Member
    edited April 2017

    @TWo said:
    We all can only assume. Why don't you just contact their support as already suggested by WSS.

    They only offer paid support. For a site I'm migrating for free, I'm not going to buy a useless plugin. I'm was willing to pay a WP expert to help me fix it if it meant that I learned something out of it.

    Anyways, we're not exactly sure what went wrong but @Junkless managed to get it working on his server. I took a backup of that and now it's working... ¯\_(ツ)_/¯

  • WSSWSS Member

    @Junkless Good luck.

  • mikhomikho Member, Host Rep

    Had a similar problem when moving a customers site between two identical (cPanel installs, or so it seemed).

    File path was wrong, one server had the user mapped using /home2// and I moved it to a server using /home//.

    The file path was stored in the database for a plugin which messed up some pages.
    Disabling plugins by renaming the folder and then reactivate them (using the original name) fixed most issues. A database search and replace fixed the last problems.

    In short; check for old file paths in the database.

    Thanked by 2AuroraZ Falzo
  • bapbap Member

    @mikho said: The file path was stored in the database for a plugin...

    Awesome plugin :)

  • mikhomikho Member, Host Rep

    @bap said:

    @mikho said: The file path was stored in the database for a plugin...

    Awesome plugin :)

    Wp-super-cache

This discussion has been closed.