I have a drupal site which I deved a few years ago. We duplicated it to a new site/domain/db (which pulls from a subdirectory of the original site)
I tried to only duplicate the site settings (views and content types), and leave out all the site node data (it is a content driven site, and we are launching a sister site). Everything wen OK. Unfortunately, in the new site, I find that I cannot update "site information" (which means I cannot set my front page). I tried to update the data in the DB, but that let to the relevant site settings field to appear blank
I i had to implement a ridiculous hack to deal with the fact that the front page is now technically a 404. Even more weirdly, the original site has the same problem now (all I can guess is that I updated the table from the wrong DB by mistake?!? ).
As best I can tell, this data is stored in "variable" in the DB. I have imported a good "variaable" table from an old copy of the site, but to no avail.
So I am completely stuck. If anybody has any leads whatsoever, I would be incredible grateful.
Thanks!
Related
Context: I have a WordPress site on Bluehost with a theme by Thrive. I set the 'homepage' to a Landing Page that I'm dubbing id 51 (post id is 51). We launched the website with a new Landing Page (id 399). This page is completely fresh, new title, new content, new everything. I changed the "Front Page" or "Homepage" in the General > Reading to this new LP. Everything seemed to be flawless. I deleted the old page (moved it to trash, but never emptied it). This same day, we noticed that when we type in our URL on this nice MacPro on Chrome, everything is fine; however, when browsing to the same URL on, say, Safari, it somehow pulls up that old content--deleted content.
I'm clearly not knowledgeable, but I can get into and investigate things:
So far, I've tried:
clearing individual browser caches from a visitor's perspective. Unsuccessful.
Purging All from the cache within WordPress
This appeared to work for maybe 8-12 hours before we discovered the browser went BACK to the BAD/OLD content. I will say, by Default, I believe Bluehost has that cache level set to 1, maybe? Assets only? 2 months ago, I set it to 3 with performance in mind while building out the website. Could be storing there? ...but I PURGE it, and it returns later... That doesn't compute in my computer. Now, I've set it to 0 and the issue is currently gone, but I'm not gonna hold my breath.
I restored the old page, id 51, from the trash, and tried renaming the slug hoping it wouldn't find it, haha. Then, I even imported the correct, modified theme template from post 399 to post 51 hoping I could just treat the wound rather than solve it. (Thrive has an "architect" feature for WYSIWYG building so I kinda cut and paste.) This appeared to work temporarily as well.
My next step was to dive into the database. I've gone through the entire thing, even unrelated website databases on my host through phpmyadmin. I can't find a single reference to the old title, slug, or its content. post id 51 has my updated information as well. In fact, it's showing all of the corrected content from when I overwrote it.
All that said, The page is totally fine, and ALWAYS fine on Chrome, but Safari browsers seem to work for a while, then revert to this pesky page. I don't know enough about how a page loads to trace 1) why it loads incorrectly on a particular browser, and 2) where it would even pull outdated, DELETED content/data from to begin with...
I just feel like I broke something, and currently, am praying to the WordPress gods that 0 caching will permanently solve this ghost-site issue...
I'll update this in a few days if the problem stays away, or sooner if it persists. Hopefully, someone can point me in the right direction. Sorry for the lengthy novel. Trying to be detailed as this is my first post and I wanna be as detailed as possible as I'm just not knowledgeable enough... Thank you.
I have built a pretty big wordpress website, and wanted to move to different hosting and domain...
I moved files, database, changed wp-config file and even changed all mentions of old domain to new one in the mysql database content.
Also, I had to change TYPE=InnoDB to ENGINE (manually), but I don't think it could cause some problems.
So, the problem is that, the website doesn't show any content, menues... etc. I can only see header and footer. Admin Panel works but when I go to pages/media It shows 0 result... nothing is there. However, phpMyAdmin shows that the pages, posts... etc. is on place.
What could the problem be?
Thanks
The problem was in database compatibility, I set it as MySql323 and it worked for me.
We have a network of Bigcommerce sites, on which we've installed several tools that are controlled by one central site, using Bigcommerce's include feature. The url passes a get value to the php, and retrieves all of the pertinent information in our DB and displays several things.
The problem is that, as of last night, all of the 40-some sites began displaying content from the newest user - the newest DB entry. I deleted the newest user, and it reverted to the user just before that.
The weird part is that when I check the url being included, the correct information is displayed.
Check it out (I've stripped out most css and js, so most relevant info is shown) -
Site URL: http://www.epicflowers.us/
Included URL: http://epicflowers.com/toolbox/fetchToolbox2/toolbox.php?store_id=123456789
The colors and the text should be exactly the same. It appears that the DB queries are returning the correct information, but the site including the url are not.
What I've already tried:
Duplicating and renaming files, in case it was a caching issue.
Ran an ajax call to retrieve the same info (which worked, but it's too slow)
This didn't seem to happen as a result of changing anything, and the PHP side seems to be working fine. No one has touched the code in a few days, but the support tickets started coming in early this morning. It's altogether possible that it's completely unique to BigCommerce.
Any ideas?
Update:
It appears the BC include is ignoring the get values at the end of the url, so http://epicflowers.com/toolbox/fetchToolbox2/toolbox.php?store_id=123456789 appears as http://epicflowers.com/toolbox/fetchToolbox2/toolbox.php, obviously negating anything unique about the store the code is on.
Any ideas on why? Bigcommerce hasn't published anything in their blog that suggests this has changed.
I have a WordPress site almost completed to live server.
The only problem I am facing is when I am renaming the URL in my database from localhost URL to live URL, I am not able to see contact us form details like From, To, Subject, HTML Body text.
All other things like widgets, pages content is fine but I am just not able to see these contents for Contact Form 7 when moving site to live by changing the URL and importing that database to live.
Why this is happening? What should I do? Or any proper method to do this?
This happened when you changed the URL in the database.
When working in the localhost environment, your url was recorded in the database and was serialised. Basically, the number of characters were counted and assigned to the url.
So, if your path was http://localhost/my-site, the number 24 is assigned to it in the database.
When you changed your url in the database to a new one and uploaded it, the number of characters more than likely did not match the original number assigned in the database. If your new url is http://my-site.com, the number of characters being 18, then the original number of 24 does not match and this causes a conflict.
The database will update itself and as a result, theme options will reset, including your Contact Form 7 fields.
You will find a better explanation here, http://wordpress.org/support/topic/theme-delicate-theme-options-lost-when-moving-to-new-domain, look to Chip Bennett's answers.
A workaround is to take a copy of your localhost database. Keep that safe.
Then, go to Settings > General and change the WordPress Address(URL) and Site Address (URL) to your new path. Now, take a copy of your database again. This will used as your database for your new site.
Reupload your localhost database to make sure the localhost site is working again if you need it.
By using the New Database on the new site, your contact form 7 drtails (and any theme options if they are being used) will now come into the new site.
I have had this happen to me a lot before finding this and ever since I started using this method, all my information has come across perfectly.
Also check out http://codex.wordpress.org/Moving_WordPress
This plugin should fix the problem:
https://wordpress.org/plugins/fix-contact-form-7-blank-fields/
It seems like others have experienced similar issues as me in the past on this subject, but nobody has provided a complete answer.
I'm attempting to run a PHP script to update the permalink structure in the wp_options table for a slew of Wordpress blogs. I want to connect to each database and update the permalinks without having to log in to each blog and update the setting through the UI.
I'm successful at connecting to the DB and updating the permalink_structure field with the proper codes, but it causes a 404 when attempting to view any posts.
Is Wordpress updating other tables/fields to fully enable the permalink?? I'm having a hard time finding the complete answer to this.
BTW: If there are edits being made to the .htaccess when this is done through the Wordpress UI, I'm not seeing it. The htaccess looks unchanged when I do this through the UI.
Thanks!
Wordpress permalink rewrite_rules are kinda troublesome. They are great if you wanna do basic stuff, but it's damn hard to do some complex rules with it.
What exact structure you wanna use?
Remember that htaccess created by Wordpress just redirects everything to index.php, which loads Wordpress system (wp_load()), and one of its components parses REQUEST_URI.
First it tries to to bind REQUEST_URI into one of its regexes, which makes it understand what kind of resource is being requested (category, tag, page, post, etc), then it tries to find which resource it is (if it's a post, find which post by it's slug).