I moved my WordPress website to another server and URL, and now my homepage is coming up blank, even when I preview it in the dashboard.
EDIT: I tried to jerryrig it so that an index.html file would redirect to a faux homepage (start.php), and I'd then change my menus. But when I used my homepage template, I got a blank result, even if the page wasn't set as my home page.
your problem is a plugin Contact Form 7 ( I just deactivate this plugin).
Pdt: Change the admin password.
It's possible these error log errors may have existed on your other site- they don't seem like deal breakers.
Here are some things I often try to troubleshoot when come across problems in moving sites:
Flush permalinks (Settings->Permalinks and hit Save)
Make sure you changed the url in wp_options (home and siteurl)
If your Dashboard is coming up, that's a good sign. Make sure your database has been imported, and that the correct theme is activated
To troublesheet, start deactivating plugins (try deactivating all first and add them on one by one)
Check that the PHP (and MySQL) version of your new server matches your old server (http://php.net/manual/en/function.phpinfo.php)
Check that the settings for PHP shorthand are the same on both servers (broke one of mine for me once: http://www.php.net/manual/en/ini.core.php#ini.short-open-tag)
Check that your php.ini file for your new server matches your old one to some extent- something breaking could be due to a different setting (this option is similar to the previous suggestions)
Good luck!
You likely had this issue before, but error reporting was set not to show E_NOTICE. This is the default, to show all errors except E_NOTICE
error_reporting(E_ALL ^ E_NOTICE);
the best way to move wordpress server is to use a importer .There are many importer plugins for that purpose .I suggest you to have a fresh installation and than import the posts that would solve your problem in the process
There is something that does an output before the header is send....
if you see the message, cannot modify header.... click on show source of the browser and look what invokes the output directly before the first <br />
<br />
<b>Warning</b>: Cannot modify header information … in <b>…</b> on line <b>…</b><br />
Related
So i have Wp rocket on my site and i saw that every time i modify a image or a text from my site, the homepage appears white with only the cookie icon visible.... i have to delete cache each time this happens and also i have to check page every time.. This i what support said but no clue.....
I enabled WP Debug while performing the following test:
I made a small edit (added a dot at the beginning of the content) and saved the settings. I visited the page from desktop and from mobile, but it rendered correctly. I repeated the test by reverting the change I made. Still, the page got rendered correctly.
So far I could not reproduce the issue, but I checked the information provided by Sandy. Based on my observations, the issue is not related to WP Rocket, but I will explain to you why you see it when WP Rocket is enabled.
Generally, when a page is rendered in WordPress your theme is rendering the following parts of the code in the exact order for each page:
header.php
template (i.e. the content)
footer.php
When the issue occurs, the template part is missing. Here is how I found it:
Sandy was able to reproduce the issue in the past and shared the code difference between the blank page and the correctly displayed page. You can find it here: https://www.diffchecker.com/AKBv9sVj/
Here is the place where part of the HTML is missing on the "blank" page. And I highlighted the last line of code that is included in both cache files:
Full-screen image: https://i.imgur.com/28DgxpT.png
That last line of code comes from header-adora-framework.php which is included with no issues:
Similarly, the next segment that both pages have in common comes from the footer:
Full-screen image: https://i.imgur.com/wsw4wHk.png
This is where the code in footer-adora-framework.php, and it is also included with no issues:
Full-screen image: https://i.imgur.com/9Nw0QDv.png
Based on this, I can see that the template part is missing. It seems your theme is not rendering the template sometimes.
I checked the debug.log that is available on the server and found the following fatal error that might be related to the issue:
Here is the main part of the error: "The template "/wp-content/themes/project-theme/templates/layout.html.php" cannot be rendered."
If you check the file mentioned in the error, you will find that this is exactly the part that is missing:
Full-screen image: https://i.imgur.com/SpLKbyH.png
The code from /wp-content/themes/project-theme/templates/layout.html.php:
Full-screen image: https://i.imgur.com/7KfMxCR.png
The reason that you see the issue only when WP Rocket is enabled is due to caching. WP Rocket "takes a snapshot" of the page the way it was rendered the first time it was accessed.
If the template did not render the template part when the page was accessed - this is how the page will be cached and you will see the issue persists.
This, however, does not mean that the issue is resolved when you disable WP Rocket.
The issue is happening, but it is not persistent as with caching. Refreshing the page when caching is not present would likely resolve the problem.
You would need to pass this information on to your theme support. Possibly they will have suggestions on how the problem can be resolved.
I try all but nonthing. I hope to fix this with your help
On the admin dashboard, I display admin notice to display the result of changes. I have production site and staging site. On the staging site, it works well. If I made changes, it's displaying the notice of appropriate message. But on production, it's same code as staging site. When I made changes, it's displaying the "cached" notice but not the appropriate message.
Here is my approach to solve this.
$flash_messages = maybe_unserialize(get_option('wp_flash_messages', array()));
print_r(flash_messages); exit;
This displays the 'cached' message.
delete_option('wp_flash_messages');
$flash_messages = maybe_unserialize(get_option('wp_flash_messages', array()));
print_r($flash_messages); exit;
I added delete_option() before get the message. But it returns the 'cached' message again.
EDIT : I cleared server cache as well.
It's really annoyed.
Can anyone help me?
Finally I found the issue is because of get_option() function is cached.
https://developer.wordpress.org/reference/functions/get_option/#source
Here you can see the function get cached data first and if not, look through db and get option.
ANSWER
wp_cache_flush();
This resolved the problem.
1) You can delete cacle from WPEngine is a managed WordPress hosting provider. They run their own caching solution, so their customers don’t need to install a caching plugin.
If you are unable to notice changes take effect immediately, then you can easily clear WPEngine cache from your WordPress admin area.
2) You can also delete cache by using wp super cache plugin
This is really puzzling me.
Here is the code:
https://gyazo.com/ba7d47653583d071d5fae6be20d8af25
When I have it as is with return view('pages.ClientRedirect'); it throws the header error. If I take away the return and just have view('pages.ClientRedirect'); the logic changes so it doesn't throw the error anymore, but obviously no longer works.
I've looked into the problem and the only answer I could find would be using rawurlencode() to encode the url, but then I get a missing view error because it's looking for an encoded url instead of the url my route is looking for /ClientRedirect
I must be overlooking something!
The problem turned out to be that Laravel's built in auth wants to direct to a specific view and I was trying to redirect to a different view, ending up in two views being called at the same time hence the error.
I fixed it by overriding the OG with what I wanted
Notwithstanding the earlier comments that you should be returning a redirect not returning a view, the most common cause of the "new line detected on return view" error is an incorrectly terminated PHP file in one of your libraries or classes. It's common convention these days to leave PHP files unterminated, e.g.
<?php
some_code();
If however one of your library files that you are including includes a termination followed by a newline then that's the cause of your error. Something like this:
<?php
some_code();
?>
(blank line here)
... that would be the cause of your problem, because the blank line is emitted by the PHP interpreter as HTML at the point where the file is included. Remove the termination and the blank line and that should solve the problem.
Well, I ran into the same Issue when I wanted to migrate my WordPress website to a new host and I battle it throughout the night. The solution that worked for me is as given below..... ..
Actually, the error was caused by a space (white space) after the site or home URL in the WordPress database:
The error message (Warning: Header may not contain more than a single header, new line detected.)
To fix this error, you can make changes to the site or home URL from within the WordPress Dashboard or through the WordPress installation's database.
Fix URLs within the WordPress Dashboard
To fix the home and site URLs from within the WordPress Dashboard:
List item
Log into your WordPress Dashboard.
In the left-hand menu, go to Settings > General.
In the WordPress address (URL) and Site address (URL) fields, make sure there are no spaces after the URLs .
Click Save Changes.
Fixing the URLs within phpMyAdmin (Manually Edit Database)
To manually edit the site and home URLs within your WordPress database:
List item
Log into cPanel.
In the Databases section, click on the phpMyAdmin icon.
From the left menu, select the database for your WordPress installation.
From the left menu, select wp_options.
Find and edit the records for siteurl and home, ensuring that there are no spaces after the domain name.
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.
Without any change on system configuration and code since my last login, one day my admin account login shows blank dashboard page, header of the page is showed but most of content are blank. Big oddity is my customer service account is able to see her whole dashboard page and get her all backends working, however, as her account has system config part disabled, I can not do anything further.
After clicking login, the URL has showed up: http://www.example.com/index.php/admin/dashboard/index/key/8062533e7ee0df2d1d693d1d70148ad8/
I check HTML rendering, header div of the page has rendered, it stopped at navigation div. the last rendering seen as below.
<div class="nav-bar">
<!-- menu start -->
Could any master help out please, I have no idea where to debug....Thank you so much...
Try:
clean all types of caches
check permissions on folders(app/etc, var,
media) should have 755 or higher.
check logs(exeptions.log,
system.log)
enable errors reporting in
index.php(ini_set('display_errors', 1);)
Thank you all for replying...It is confirmed due to shoplift bug. I applied all patches including latest 5994 patch, nothing changed...I turned on error display in index.php, indicated an error file from includes/src, so I asked hosting admin to turn off php compiler, then I got my admin login back to normal....
However, not sure if this is side effect of the bug, I can not see all images of all products from backend, they all gone. weird thing is all images are good to see from frontend...does anyone know how to do housekeeping after site was being attacked by hacker?