So I've got PageSpeed on top of Nginx serving a pretty simple Wordpress install.
This problem seemed to coincide with upgrading to Wordpress 4.2.2; however, after downgrading to 4.1.5 to see if this was the issue, it turned out not to be the case.
Normally I wouldn't blame PageSpeed, but using ?PageSpeed=off in the URL fixes the issue completely. And just to be clear -- there's no cache in the admin area.
Another odd thing is that it only seems to effect Pages (as opposed to Posts) in the CMS, so it seems like PageSpeed might have some conflict with scripts/styles/something specific to Pages.
I am currently baffled, so any suggestions are appreciated.
Open the file "pagespeed.conf" search for:
ModPagespeedRewriteLevel PassThrough
uncomment this line and change it to:
ModPagespeedRewriteLevel CoreFilters (is save for most websites)
if this line above not helps try to change into:
ModPagespeedRewriteLevel OptimizeForBandwidth (stronger guarantee of safety)
see also the online reference about this subject at PageSpeed: https://developers.google.com/speed/pagespeed/module/config_filters?hl=nl
Related
I’m working on correcting a styling of an element on an WP-based eCommerce site.
The site has both SCSS and CSS files.
To make things quick, I edited the CSS via Appearance -> Customize -> Additional CSS.
However, when I was done and published my changes (and solved the issue), only those new to the website sees the difference.
Those who have visited the site prior to the deployment of the solution, still see the distorted number layout
I also suspected that the SCSS gets compiled every refresh but when I checked the File Manager (cPanel), only the CSS files get modified.
I’m feeling this might be a cache-related issue. I have already disabled a cache plugin (WP Rocket). However, the problem still persists.
What possible issue am I experiencing?
Edit: I did try to use Incognito and the change did reflect. However, the users of the site are non-techy people and don't know how to refresh.
The site is using GoDaddy as the host. Is it possible the issue is on that part?
Thank you
I’m using the latest version of Wordpress (4.7.4).
I have something very weird going on in my Dashboard. Not sure when this started.
Can’t say for sure it started with the latest version of Wordpress or not.
My Dashboard became completely useless.
It’s like it’s showing me a flashback of a Dashboard from a few days or hours ago:
Comments I’ve deleted in the Dashboard (hitting “trash”) are suddenly back there, awaiting my moderation.
Plugins I’ve deactivated or even deleted are all back there and according to Dashboard still running (while in my FTP folder they’re certainly gone).
The plugin page cannot be trusted anymore as it shows some plugins are activated that aren’t and vice versa. I have to check on my actual website to confirm which ones are running.
Updates aren’t shown correctly. Once I’ve updated a plugin, a few minutes later it shows me again that there’s a new update.
As you can tell it’s all pretty much the same phenomenon.
It’s as if I’m seeing an older version of my Dashboard.
Not sure what else is broken.
The only other thing I noticed is that even on my actual blog I still see a comment. Blog post says “1 comment”, but the actual comment doesn’t show up.
At first, this all sounds like a “cache problem”.
But I’ve already turned off all caching:
No caching plugin installed
Turned off server caching via htaccess
Disabled leverage browser caching
Emptied my own browser cache
Other things I tested:
Turn off all plugins.
Switch to the standard Wordpress theme “Twenty Twelve”
I tried WP_DEBUG, but nothing related shows up.
I researched the internet, but nobody has described a similar problem, so I suppose this is not a common Wordpress issue.
The issue remains.
Unfortunately I’m not a developer and don’t know too much about the Wordpress codex etc.
But to me it sounds that the mistake is definitely not in the plugin or theme folder.
The problem is that I’ve reached the point where I really cannot turn off plugins via Dashboard properly anymore. It’s so annyoing!
My questions are:
Is it safe to assume that this is related to the Wordpress core
files?
What files exactly are in “charge of” the Dashboard?
Should I just try to re-download the newest Wordpress version and replace a few files (if so which ones)?
Should I do a clean Wordpress re-install or would that be too drastic?
Any other suggestions?
EDIT:
Additionally I tried now:
I manually downloaded the newest version of Wordpress and did just as
described on the Wordpress.org website. I manually replaced wp-admin,
wp-include folders and all root files. The issue remains...
The way my Dashboard is right now, I really can’t use it.
Please advice!
I contacted my host service again.
They just gave me the same line to insert into my .htaccess file and I told them I already tried it and it didn't work.
I then showed them my .htaccess file and they deleted the whole part that concerned their server caching.
Now server caching is completely off and everything works again.
Still not sure why this previously never caused issues.
In the end, it had nothing to do with Wordpress.
I hope this answer will help people who run into similar problems.
I'm working on a Wordpress instance with some plugins.
Everything works great after it starts serving 404 code. Seems to be random because everything works fine and in some moment the rewrite rules seems to break and the links stops working.
Sometimes it is happening when I update a content (we are using custom content types with this plugin https://wordpress.org/plugins/custom-content-type-manager/) but sometimes without touch anything (for example a weekend in the middle of the night).
We have been checking all the solutions we found but nothing works. The htaccess has the correct permissions and it is rewriting well the urls.
After debuging Wordpress, the problem seems to be that for some reason, it is reseting the rewrite rules to other than the correct ones (here you can find both dumps, the one when the site serves 404 first, and the second one with the correct rules https://es.forums.wordpress.org/topic/permalinks-error-404?replies=5#post-53705).
Also, we check what was the wp-cron running but we didn't find any plugin that touch the rules (I am not sure if WP doed anything with the rules periodically).
Thanks in advance.
Germán
I'm seeing this with a multisite install. It seems to correspond to codebase changes in WP core.
I was recently hired by a new company and one of my duties is upkeep on old sites. It's recently been brought to my attention that one of Wordpresses is broken in IE9.
www.nexoslatinos.com
I've tried deactivating all plugins, no fix.
I've tried switching to default themes, even they appear broken.
I've opened the developer tools in IE9 and it's rendering the site in what it calls "Quirks Mode"??
The theme is for the most part identical to the theme found in the spanish translation version:
www.nexoslatinos.com/espanol
which is rendering fine in IE9. When taking the Spanish translation theme and applying it to the first wordpress, it breaks. The two themes also run identical plugins. They are however, different wordpress installations.
When I view the source for the page, I am getting a strange line of code before the doctype:
<!--331c6883dd6010864b7ead130be77cd5-->
Could this be throwing off IE9? I haven't been able to locate the code's origin, but it stuck out when reviewing the site in my initial troubleshooting.
The code for the theme is a bit of a mess and isn't valid, but despite that is displaying fine in Chrome, FF, and Safari.
Thoughts? Insights?
That comment (not code) is an MD5 hash of "pizda" -- which is a eastern european pejorative meaning vagina in various languages. You can see this http://en.wiktionary.org/wiki/pizda for ethnological details.
Check your WP theme for code fragments that might look suspicious. If it's not there, check apache configuration for a site-wide server-side include (SSI).
Don't mean to alarm you as I didn't look at the site, but I would check files, database for malware, whether server-side, client side, or both. Not 100% sure, but additionally there is a pizda kernel exploit - you may want to have the hosting machines checked.
This sounds to me like it could be a file encoding issue. I would recommend checking to make sure all of the php files that make up the theme as well as all Wordpress core files that might have been modified are UTF-8. You can do that in your code editor, or by checking each file here: http://people.w3.org/rishida/utils/bomtester/
A quicker way to narrow down the scope of potentially problematic files might be to create a clean dummy Wordpress installation and activate the seemingly problematic theme. If the problem is still there, it's got to be a problem with one of your theme files. If it's not there, I suspect that there might have been some unsound edits made to the Wordpress core files.
I got a problem that's driving me up the wall: I made a Wordpress Blog, using the Gantry framework for layout en several different widgets and plugins. Everything works fine in FF, Safari, and Chrome, but trying to open the site with IE 8 the browser crashes or in the best cases I get a message that the tab has been closed and reopened due to an error; after which the site is loaded fine. I try finding out what happens during the opening of the page, but the debug panel of IE doesn't point out any error!
Does anybody have clue on what the problem might be?
The website is: http://www.danielevecchiotti.it/
I suffered from the same attack today, so I investigated a bit:
That injection is done through the hole in one of the plugins, most likely through the outdated contact-form-7 plugin. Check if you have this folder in your wp-content/plugins directory - even if it is not activated in Wordpress, the very presence of it there is a potential security threat as the attacker can use the direct URL of the plugin faulty file to access it.
(source: http://wewatchyourwebsite.com/wordpress/2011/11/wordpress-websites-infected-through-outdated-contact-form-7-plugin)
Patching the hole: if you use this plugin, update it to the latest version which is not vulnerable. If you don't use it and just keep it deactivated (like I did), you can remove it at all.
It is also a good idea to prevent people from accessing your plugins directly. You can create a wp-content/plugins/.htaccess with the following content:
<Files *.php>
deny from all
</Files>
This might not work with every configuration, but usually plugins are only accessed in the code, not with HTTP calls so that shouldn't do harm to visitors' experience.
Restoring your site: If you don't have backup of your *.php files to restore them all from by overwriting your current ones, you need to search for every file containing the string specific to the malicious code, e.g. "eva1fYlbakBcVSir". Then you need to edit all those files - for every file, remove a long line from it's end.
Or if you're proficient with command line and, say, perl, you can build a regular expression to do the work for you.
What was the purpose of the attack? Obviously there were links to some Java plugin added to your site's pages by those code snippets. The plugin added is believed to be the following: http://www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?name=Exploit%3aJava%2fCVE-2010-0840.KM&threatid=2147649278
However, I didn't manage yet to decipher the injected code fully - it's very well messed up and the reverse engineering is hard. So I can't tell for sure that apart from showing that Java plugin to visitors the exploit was doing nothing like reading users' passwords or removing some files (unlikely, but possible).
I can't find any information about that as well, looks like nobody traced the consequences fully yet.
Please share if you know more.
I finally found the problem: the site has been HACKED!
I noticed the index.php and wp-blog-header.php files modified on a strange date and time. Downloading the two files I found they had been compromised: a whole section of unreadable code had been added. Uploading the original PHP files the above problem was solved.