I'm developing a website on EC2 and have the development and live site hosted on the same server (for $'s sake).
What I'm encountering is caching conflicts. Specifically on the dev site I have things that are not intended to be seen by the public yet but because it seems that both sites are using the same APC cache the entries are conflicting, and so the public is seeing things it really shouldn't yet.
The dev environment is a complete copy of the live site just checked out from subversion.
Both sites are available on different domains if it helps tailor the answer.
Any suggestions on how to make sure this doesn't happen?
I've drilled down into the AuthCache code and found that there are many things that can cause a page not to get cached. Among them is isset($_COOKIE['nocache']). This means that I can set $_COOKIE['nocache'] on login in my own module when the request is being performed on the on the dev site.
Related
I have a website that is running on an AWS server using the Bitnami Nginx and WordPress image.
https://www.athleticclubhk.com/
Recently it got all our ads on Google stopped due to malicious content. Oddly this time, its trickier then your standard malware of infected files. When visiting the site incognito, the first and only the first link click gets redirected using the following code:
window.location.replace("https://cartoonmines.com/scount");window.location.href = "https://cartoonmines.com/scount";
This is being injected on any link, however, upon investigating the loaded code on inspect its not injecting it into the page.
I've tried to hunt down the theme, plugins, core files and found nothing!
I replaced and reinstalled WordPress core files, deactivated all plugins and even swapped the theme - the problem is still there. I can't find any hidden .htaccess file in the entire root directory.
I even used GREP to try to look for anything fishy (any clues here that someone can help with?) nothing so far.
The site is still impacted with this so you can easily load the link ~ i do use malwarebytes to keep myself protected, incase you are opening this directly.
Can anyone help?
The redirection code is implanted to /wp-includes/js/wp-emoji-release.min.js.
How to confirm:
watch the cookies when clicking internal page, a new cookie is being set for tracking first clicks, named ht_rr
save complete webpage locally and try to load it, and check in Chrome dev tools, you'll see that in Console tab it complains about this Javascript file attempting to set the aforementioned cookie
While a temporary resolution of deleting the file will fix things for some time...
There's no excuse for not setting up a proper server stack. Bitnami or other "great stacks" won't cut it security-wise. They exist for "fast", but no "quality" setup, and of course, it's never going to be secure.
The file got created somehow / had write privileges. This indicates a problem with the setup most of the time. Unless you're using some nulled plugins or plugins from bad sources.
Once again, since the website was essentially "pwned", deleting the Javascript file does not mean complete disinfection. To preserve things in a secure state, I would recommend setting things on a clean server environment with strict PHP-FPM permissions aka "lockdown" chmod, and look for write errors to look for infected PHP files.
Check out some guides on the matter of secure NGINX/PHP-FPM setup:
NGINX and PHP-FPM. What my permissions should be?
Best practice secure NGINX configuration for WordPress
NGINX Security Headers, the right way
Just had the same problem and it was Zend Font Plugin, the same that some people mentioned before.
Installed Wordfence and this came out. Deleted the plugin and now the site is working perfectly.
Disable plugins and check again.
Change the database username and password.
Ask the hosting manager to check the host.
I'm facing a problem with the following website: https://www.rhythmandstrums.ie/
When I open the "www" version of it: https://www.rhythmandstrums.ie/ I get a bugged website, failing to open stylesheets and possibly other file sources, whereas if I open the website without the "www", everything works as expected: https://rhythmandstrums.ie/
Some considerations:
This website is hosted in a Wordpress Multisite, so it shares the same configuration files as other websites, none of the other websites have this issue. So I was wondering if this could be a problem with redirection, although, again, none of the other websites have this problem and they share the same config files (including server block settings and such, it is in nginx).
I have checked the DNS values and nameservers and everything looks fine (I took base from all the other websites that were set up in the same way, I can post a screenshot if it might be of help).
This error also seems to happen in the Wordpress backend, with the admin dashboard not being able to load parts of plugins, it seems like it is looking where it doesn't exist.
I have replaced instances of the www version of the url in the database, as I do with other websites as well, but that didn't seem to fix the issue.
I have cleared cache a few times (both in the cache plugin and manually in the nginx server - manually deleting the contents of the cache folder), and since this has been going for a long time, I don't know if this is cache related, but any suggestion is highly appreciated. Again, all the configs, included the cache plugin settings are the same for all the other websites in the network, which none are having this issue.
If I inspect the console when I'm accessing both versions of the website, www and non-www it seems like it's trying to pull information from different locations, but I can't figure out why it's doing that.
Guys, I hope this was not confusing, but let me know if you you would like to see screenshots or other info that might be relevant. Thanks so much in advance, I really appreciate it.
I'm currently working on a clients website where we want to split up the live environment into three different ones.
We currently want the following envs:
Production (Live website)
Preview (Unpublished live website for content management)
Staging (Development state for feature and development previews)
We have them setup via the following subdomains:
Live:
de.xyz.com
en.xyz.com
ch.xyz.com
Preview:
de.preview.xyz.com
en.preview.xyz.com
ch.preview.xyz.com
Staging:
de.staging.xyz.com
en.preview.xyz.com
ch.preview.xyz.com
NOTE: We're also using the WP cache with advanced-cache.php in combination with WP Engine Advanced Cache. Maybe thats a conflict?
Anyway, when I now login to the different backends and try to map the subdomains and save somehow the environments overwrite each others settings again, even though they are on separated webservers and use separated databases.
I'm really confused because when I for example set en.preview.xyz.com on the preview domain, somehow the same en.preview.xyz.com value is set on the staging environment.
Are there any known conflicts with WPML Subdomains and multiple Websites on the same parent domain or a caching plugin?
Thanks already a lot. My client already is kind of annoyed because the content managers are waiting.
Greetings!
I found the answer for my problem.
Basically the WP Supercache Plugin was setup wrong to work with different environments. I had to load the WP_CACHE_KEY_SALT from the .env-files in the object-cache.php
We are developing Wordpress sites and due to some issues with some plugins once the domain is changed (from dev.domain.com to www.domain.com), we have been using a practice of editing host files in house so that we can develop the site on the www.domain.com domain.
This solution works fine for us in house, however when a client wishes to see their site in development we have to walk them through the editing of their host files to see the development site and then back so they can see their live site.
Does anyone have a better idea or solution. Is there a way to make this work at the Apache level? Maybe a Chrome app? It needs to be super simple and automated (scripted) if possible.
Thanks
You could create an VPN connection to your "house" so that the fake www.domain.com will be avaible for them.
So, the issue is that some plugins think they're on www (or will only behave correctly on www)?
Then quite possibly your best quick bet is a Chrome/Firefox extension, although obviously that does require the client to have them installed.
I'd recommend looking at HostAdmin for Chrome and/or fire-hostadmin for Firefox. These should allow you to amend the hosts without too much hassle or direct editing of protected system files.
It is always worth noting that, depending on the client's computer's security, they may run into potential read-only issues (I believe SpyBot Search & Destroy and similar tools lock the hosts file by default).
Been having a bit of a problem with my site regarding our caching method and my php code not refreshing or flushing.
To start, my site is a WordPress site on a dedicated Nginx webserver. I used W3 Total Cache for the initial caching setup. Everything was set up to cache through Memcached.
(I should note, my website is somewhat of a 'guest' on this server, which is bit of a semi-community donation semi-sponsored server that runs some other things. The admins are skilled but also volunteers. I have their full support for fixing things, but they don't have time to troubleshoot my very odd issue (especially because I asked for caching to get turned on for the site myself). If we had some hints on what to go on it would make things easier for us than taking shots in the dark ;) So any suggestions are welcomed.)
At some point we noticed that changes to php pages and Wordpress & Plugin updates were not working at all, while the code on the server reflected updates, the pages still processed through the older php code.
This presented a couple unique issues. W3 Total Cache stores it settings in php files. Other php files, when deleted, stop working, but when they are restored to the server, memcached still insists on using its ultra-old memcached copy. The W3 Total Cache settings, whether i removed or altered the settings php files, would NOT stop running everything through cached memcached data.
The server admin attempt rebooting memcached and then flushing it. Neither of those seemed to have any effect. All the other basic settings seem to be set-up correctly.
We can, of course, still add new plugins, all the data that comes from the database works just fine.
At least one other site on the server that is not wordpress also uses memcached with no issues.
Any help is appreciated, should be able to provide further information if it is needed.
Do you have apc.stat = 0 in your settings? Does restarting php engine help?
This is going to sound really obvious but you didn't mention it so:
Did you try turning off the Total Cache plugin entirely to confirm you can see the changes when caching is disabled?
Until you've done that and made sure you get the results you expect, there's no way to know that memcached is really the problem.