-
I have GP Premium and basic Generateblocks installed on an addon domain at old-addondomain.mysite.com
I bought a new domain and created a new folder on my host and named it new-addondomain.mysite.com
I copied the entire wordpress install to the new subdomain’s folder.
I used phpMyAdmin to replace all instances of old-addondomain to new-addondomain in the site’s MySQL database
I updated the WordPress general settings to the new domain name
It runs okay now, but I notice that the fonts are missing and some items are not working properly, like the gallery block, the menu is not formatting properly, and lots of other cosmetic problems. It looks like a Theme problem, i.e. GP Premium.
I cannot think of where else the old string “old-addonbdomain” could exist. Does GP store any domain details outside the MySQL database? Thanks!
BTW, I have flushed the Litespeed cache and the Cloudflare cache and used a new browser….
-
Hi there,
but I notice that the fonts are missing
What font is it? And where can I see the text with this font assigned?
some items are not working properly, like the gallery block
Unfortunately, we don’t have control of the gallery block, it’s a WP block.
-
Please see private data for a link to a screendump of what the site /should/ look like
Notice that the page title is being displayed on the new, broken site, and it shouldn’t be
Notice how menu is broken
-
Hi there,
Can you deactivate the LiteSpeed plugin while we debug the layout issue? Some CSS might be cached by LiteSpeed, so turning it off completely will help us debug properly.
-
Thanks Alvind, but I think I will leave this issue for a few days because I suspect it may be a domain propagation issue. Once my domain changes are fully propagated and working, I see if the problem still exists. If it does, I’ll return here with the caches (Litespeed and cloudflare) turned off.
And if the domain propagation DOES solve the issue, I will request that this topic be deleted.
AI says: “Domain name propagation delays, where updated DNS information takes time to spread across the internet, can cause temporary website problems like downtime or inconsistent experiences, as some users might see the old information while others see the new”
Thanks, stand by ….
-
May I ask a very basic and easy question please? Does GP Premium have any .php files within the WP install folders that contain site-specific variable data, or are all variables stored on the MySQL database for the site?
In other words, are all GP parameters for a site stored on the database, or are some stored outside the database?
Thanks!
-
Does GP Premium have any .php files within the WP install folders that contain site-specific variable data, or are all variables stored on the MySQL database for the site?
When you mention “site-specific variable data,” are you referring to the Customizer settings?
If so, yes, they are stored in the
wp_optionstable. -
Are GP Premium and free GenerateBlocks stable with WordPress 6.7.2 ? Could this be behind my mysterious formatting problems?
-
So, it turns out that ONE of my problems is that your plugin GenerateBlocks is storing variable data outside the database, in an UPLOAD folder somewhere in WP-CONTENT.
This is very poor practice and has cost me many hours of work.
-
The only thing GenerateBlocks stores inside the
/uploadsfolder is the generated CSS files. Other than that, there are no critical files or variable data stored there.When you copy the entire WordPress installation during a migration, those files should be included as well.
-
What do you mean “no critical files other than that”…? These CSS files are indeed critical and contain hard coded urls. I don’t have any other plugins that store variables including hard-coded urls inside the wordpress installation and not in the database where they should be! This means that one cannot simply move sites around because you’ve got hard coded information locked outside the database, which is very poor coding standards. Are you even aware how bad this is? Please get a comment from Tom.
-
And one more question for Tom: is he aware of any reason that a SEARCH and REPLACE of a domain name in the database, which would affect many rows used by GeneratePress, would break an installation?
Bear in mind that I have tried twice now to change my domain name on the MySQL database, with great care, and both times the site ends up broken, with things like the site title now being displayed (it never was before), the page content no longer centred, and other strange formatting (and therefore probably CSS) errors.
Does GP or GB have rows on the database tables that are positional in nature, in other words where shortening or lengthening a string of text (such as the domain name) would corrupt the data?
Thank you.
-
Hi @mmeaker,
I hope you don’t mind me jumping in, but this is a long discussion and keeps appearing at the top of my list so I have been following it with interest.You said at the beginning that you manually copied the WordPress Folders/Files to a new location & imported the SQL.
This is unlikely to work completely, as the links that WordPress stores are in a format called ‘serialised PHP data’
In other words they are not plain text. And simply importing the sql will not update those links!It is better to use a backup/restore plugin such as ‘All-in-One WP Migration and Backup’ or WPVivid that understand this format and updates all the URL’s to match the new URL.
They also ensure everything is copied over, eliminating any missed content.
If not too late I would suggest investigating one of these tools that do an excellent job of migrating sites.Best Regards, Dave
-
Thank you for your comment, Dave. I installed the plugin you referenced (All-in-One WP Migration and Backup) and it did find instances of the string in serialised data, but only the paid Pro version will find and replace it. So I installed the plugin “Search & Replace Everything” that performed the task for free. Result? Despite refreshing the Litespeed and CloudFlare caches, no change. Sigh!
How on earth could this have happened? I’d really like to know. It’s weird, I go to the Customizer and under Customize site identity the ‘Hide site title’ checkbox is unchecked, whereas it was checked before I made the changes (this is only one of many strange formatting errors). I realize I’m going to have to build the site from scratch again (weeks of work lost), but still, as a person with a programmer and systems analysis background, I’d love to understand exactly how these errors occurred.
And regarding GenerateBlocks, I still insist that it is bad practice to have site variables and hardcoded URLs stored in the installation folders. That’s what the database is there for, specifically. I scanned the entire WordPress installation for my URL string, and the GB plugin is the /only/ plugin that was storing it outside the database. At least tell me you are going to fix this! My confidence in Tom and his team is shaken at the moment.
-
Hi @mmeaker,
Re this:
“but only the paid Pro version will find and replace it”
This is simply not the case – if it was why would anyone use it!I often use the free version to quickly move a site if I don’t have my paid version installed.
The main limitation is that the free version has a limit on the backup size (and specific paid versions that backup to cloud storage – e.g. I use it to backup on a schedule to Amazon S3)If you do have a size of the backup issue, try WPVivid, it does not have that limitation!
What was the size of your backup file?Did you backup the old location and restore to the new location ? It maybe not re-reading your reply – I suggest starting from scratch & see if that works.
Let me know ?
Daveps – those folders that hold the CSS are auto refreshed when there it a change, so there is nothing hard coded in them. (pretty sure, GP/GB staff can confirm)
-
Dave, thanks for your time again. What I meant was the plugin you suggested was only able to replace via a download-upload sequence, and for my large database that would be a chargeable event. The other plugin accomplished it without charge. I realise in retrospect I could have perhaps made the download smaller by excluding items (I think), but that’s academic now.
The point is, the errors have not gone away, and I don’t have a pristine version of the database to revert back to again, and anyway I’ve decided to move on from this and make a new website, using a more modern template, which may be a positive thing in itself. The old one was getting long in the tooth and needed a refresh anyway.
I see my complaints about how GB works have been more or less ignored, but the lack of defence from the staff here HOPEFULLY means it is in the process of being redesigned so that it uses the database, like other plugins. No plugin should ever store variables, especially URLs, inside the installation folders. That’s just plain bad practice from a programming POV, and it leads to exactly the kind of the problems I’ve had (IOW when the site is moved, and the database updated with new URLs by user or more usually, a plugin, those references will be missed).
I bought GP because I believed at the time in the technical prowess of Tom Usborne and his team, and I want to keep believing that. Come on guys, restore the faith!
- You must be logged in to reply to this topic.