If you have siteground hosting (could be the same for other hosts) and maybe WordPress site and you just edited a style.css file, reloaded your page but you cant see the changes (they appear after some time) then it is probably a Super Cacher issue.
Go to your siteground cpanel, find SuperCacher under Site Improvement Tools and click it.
Then find your domain, click Flush Cache then turn it Off.
Here is some more info:
So one approach you could use is this : turn off cache while you are editing the files (through FTP, not in wordpress admin) site. Once you are done just turn it on again.
This is a very specific problem so it might only work for some. After I updated WordPress and all plugins on an old site that used WordPress Custom Fields to enter some data, the Custom Fields in admin disappeared. I could add a new post but Custom Fields were nowhere to be sen, not even in the screen options.
Long story short, after doing some searching on the net, I found out it was ACF (Advanced Custom Fields) fault. In new version of the plugin they disable WordPress Custom Fields because they think you are using ACF anyway so no need for both. Not sure I agree but here is 2 ways you can try to solve it:
- If you activated ACF but are not using the plugin, just disable it. WordPress Custom Fields should come back.
- If you want to keep both then add this code to your theme’s function.php file (the best is the child theme, if you have one)
WordPress Custom Fields should reappear now.
I am using Contact Form 7 on one of WP sites and after update (not sure which one) I started getting this error after user submitted the form:
‘Failed to send your message. Please try later or contact administrator by other way.’
As always, lots of way to complicated solutions on the net when, in my case, the solution was simple.
This is what I had before (CF7 admin):
And this is the one that works (I just replaced data in the FROM field):
of course you need to replace domain.com with your domain.
I do not know why did it worked before and why it stopped working but this is how I solved it. Of course you cant just hit reply now because your email is REPLY email. To solve this you can try this :
Contact Form 7 has a field called “Additional headers:”. Enter (literally)
Reply-To: [your-email] and save.
It is easy to get a post ID in WordPress. To echo it on screen we write:
<?php the_ID(); ?>
To store the ID into variable we use something like this :
$id = get_the_ID();
There is one caveat though: if you read the description on WordPress codex it says this in both cases: This tag must be within The Loop.
So if you ever wanted to retrieve or display the WordPress post ID in footer or header or outside of The Loop you might end up being disappointed because the ID returned is not the correct one (usually we always get the same id, most probably the last one?)
Now I am not going to go into technical details or why is that so here is the solution that worked for me. You
$post = $wp_query->post;
There are some other ways with global variables and some other but it seem it doesn’t work for everyone. This one worked on the first try. Let me know in comments if it doesn’t work for you.
There is nothing worse than getting blank screen when developing for WordPres – also ‘officially’ known as The White Screen of Death – because you have no idea what went wrong. No errors, nothing useful, just blank screen. It’s even worse when it just appears out of nowhere. This happened to me few times in the past and then just recently. Woke up in the morning and the entire site (not this one) displayed just blank white page.
First thing you should do is rename the
plugins folder and see if it works. If yes then the problem is in one of the plugins so if your admin works start disabling plugins one by one. If admin doesn’t work then try renaming plugin folders via FTP. If this doesn’t help then rename the
themes folder and see if the problem was caused by one of your theme.
This didn’t help in my case. So I went to WordPress site (link below) and insert the code they recommended! It STILL didn’t work and there were no errors displayed! So finally I modified the code a little and finally the error appeared! I don’k know why are they posting a solution that doesn’t display the errors.
Here is the code that started showing errors and I finally able to fix it. Still the mistery remains why did the blank screen start appearing when it was working just fine yesterday when I went to bed. Ah, the ‘joys’ of developing.
wp-config.php file in the root directory of your worpress and insert this just above the
/* That's all, stop editing! Happy blogging. */ comment. Refresh the WordPress and hopefully you will see PHP error telling you what went wrong.
// Enable WP_DEBUG mode
// Enable Debug logging to the /wp-content/debug.log file
// Enable display of errors and warnings
// Use dev versions of core JS and CSS files (only needed if you are modifying these core files)
After you fix the error don’t forget to remove or at least comment the added code.
In case it didn’t work, here are some more steps to try to fix it:
Common WordPress Errors and Debugging in WordPress
This is for WordPress but can be used in any site because it uses
I needed to redirect all visitors that visit the root URL (for example
elcoderino.com) to specific subpage (eg
elcoderino.com/subpage). WordPress allows you to create a static front page or select a custom page that will replace default front page content but in my case it just didn’t work. Maybe it was combination of Advanced Custom Fields or custom post types but it just kept messing up the front page.
So the solution is to add this to your
RewriteRule ^$ /subpage/ [R=301,L]
.htaccess file already contains
RewriteEngine On then simply just add
RewriteRule ^$ /subpage/ [R=301,L] below it.
I used to use Xampp but I decided to try Wamp for my new WordPress project. After installing WordPress on local machine and chaning Permalinks to Post Name in admin I suddenly started getting these errors:
The requested URL was not found on this server.
Don’t you just love it when such errors appear? I forgot how I solved this in the past projects but remembered it has something to do with
.htaccess. After Googling and trying out few solutions nothing worked until I realized that with Wamp you can enable mod_rewrite via WAMPSERVER Control Panel (you will find it in your tray).
So just click on
WAMPSERVER icon, then
Apache Modules and then scroll down to
rewrite_module and enable it. Restart Apache (or restart all services) and your permalinks will work.
Seems like qTranslate is not really updated anymore or at least it is updated very slowly. So when I updated WordPress to new version I got this message and qTranslate editor in admin was disabled.
The qTranslate Editor has disabled itself because it hasn’t been tested with your WordPress version yet. This is done to prevent WordPress from malfunctioning. You can reenable it by clicking here (may cause data loss! Use at own risk!). To remove this message permanently, please update qTranslate to the corresponding version.
I guess the easiest way is to just click on the link and it will probably enable itself. I googled it and it seems some people might have problems with that. So the solution that worked for most people is this:
wp-content/plugins/qtranslate/qtranslate.php file and change line 90 from
just save it and that’s it.
Of course if WordPress is updated to new version qTranslate will disable itself again. What you can do is enable it for all version by dynamically inserting current WordPress version, like this
qTranslate will now work for all (future) versions of WordPress.
Hint: You can find out your WordPress version on the bottom right in the admin or by opening a file
/wp-includes/version.php and checking the
$wp_version variable on the top.
Note: Do this on your own risk. It seems to work for most people but beware you might loose your data if something goes wrong. The safest way is to wait for author of qTranslate to update it but it seems this is not happening.
WordPress update stuck in maintenance mode
In some cases the message “Briefly unavailable for scheduled maintenance. Check back in a minute” doesn’t disappear after you update your WordPress, despite the update being successful. Even worse – you are locked out of admin because both admin and your site display this message.
How to fix the WordPress maintenance mode problem? The solution is simple. Use your FTP program to connect to your server and delete the
.maintenance file from your server (it is in the WordPress root directory, same as .htaccess). In most cases this will fix it. If the update did not finish then loginto admin and try to reinstall WordPress updates.
When you want to install or upgrade a plugin, WordPress will most probably display this message:
To perform the requested action, WordPress needs to access your web server. Please enter your FTP credentials to proceed. If you do not remember your credentials, you should contact your web host.
If you are on shared hosting you might not have this problem but if you are on a VPS or Dedicated server you will most probably get asked to supply FTP credentials every time you want to install or upgrade plugin or even WordPress. This can become an annoyance if you install plugins a lot so this is one of the first things I always fix when I install new WordPress site.
Here is how to solve it: open your
wp-config.php file (by default it can be found in your root WordPress directory) with text editor and simply add your ftp login information near the bottom of the wp-config.php file (just above the /** Sets up WordPress vars and included files. */ comment for example):
//*add your FTP credentials*
//*If you like and can use a SSL connection set this to true*
After you do this your won’t be asked for FTP credentials anymore. There are other solutions like settings permission with chown via shell or installing suPHP on your server but this one seems to be the easiest.
If the above fails for whatever reason you can comment the above code and try adding the following code in the
wp-config.php file,somewhere at the top:
define( 'FS_METHOD', 'direct' );
define( 'FS_CHMOD_DIR', 0777 );
define( 'FS_CHMOD_FILE', 0777 );
This forces files to be writable by the server. You should only use this if adding FTP credentials method fails.