Caleb
Forum Replies Created
-
BTW.. WordFence do not even see or control the loading of asset files, such as file-images, font files, CSS files and others, because they do not load up through PHP or WordPress at all.. They are pulled directly by the web-server; if allowed by it’s rules.
Only uploaded images (which are actually represented in your pages as WordPress links, not as file-system files) can be seen by WordPress/WordFence.
Your shown error log show these as blocked because they are cross-origin requests. Invalid between different-domains requests. Not a WordFence thing.
The hacker do not need your WordFence email to find a link to your site. They know it.
They do not need access to your email account either. Just an address.
The hackers have no problem knowing your site. Or generally knowing all the millions of domains running WordPress. They already know. Just like comment spammers know. WordPress run sites are as obvious as the nose on our faces unfortunately.
But they need you to be used to clicking on or expecting an admin link in an email.You are right, however, that some WordFence alert emails seem to contain up to multiple links back to your site’s admin pages already, which makes adding just one more such link kinda make no difference at all.. 🙂 If the door to phishing is 90% open already, then opening it to 99% makes no never mind. 🙂
The daily “Problem” email from scans with Plugin updates & such, though, has no site links in it. At least mine do not.That some obscure, random WordPress programmer added a link to a WordPress email means nothing to me. My experience is that most programmers of such side-order code do not think of security at all. Just watch all the “security patches” we keep receiving for all kinds of products; repeatedly, often, and again. 🙂
My final commentary on this topic.
Despite what you are thinking, millions of people have had their Banking and other financial credentials stolen using this exact type of Phishing method. Banking email are just a little easier to spoof than random web-sites, because you can just blanket the world with Bank of America fakes, assuming that a percentage of them has accounts there. Not quite that statistically easy with WordPress emails.
That individual goofy, and quite frankly VERY frequently security ignorant programmers of such things as a Backup Plugin or a WordPress Update notice don’t always think of these things seems irrelevant to me. Heck, even banks still send out emails with links in them, purely for “customer convenience”, despite also sending out warnings never to go to their sites using such email links, because people are faking their emails. 🙂
One hand not knowing what the other is doing.But.. If a Security Plugin like WordPress became a phishing medium, that would be quit laughable. Since they would definitely be assumed to know better. 🙂
I used to hunt phishers & such creatures.. You learn to dislike email links, when you are for example tracking seemingly legitimate Wells Fargo banking email-links through typically 3-5 infected web-sites in various countries following encrypted/obscured jump-links. Before finally landing on a phishing- or virus-infected site in eg. Russia or Moldovia..
I can guarantee, that the normal web-users would not notice that their browser executed a series of Redirects, before settling on a legitimately looking page.So, if I had a vote on the subject (which I obviously do not), I would vote not to have a Security plugin do such insecure things as sending out email-links back to the Administration pages of the site they are supposedly protecting. 🙂
Just my opinion.Yes, Opcode Cache (Zend Opcode cache) cannot traditionally (without some special programming) cache anything except OpCodes.. (It does not cache the PHP files, but their “compiled” intermediary codes.)
Since PHP is not normally a real “compiled into machine language” language, but is merely compiled into Opcodes, which are then “executed” by the PHP interpreter.
I say “normally”, because there actually IS a full-blooded compiler-to-machine code for PHP.. Used if someone needs real speed. (Facebook picked it up and invested in making it complete, since they need better than interpreted PHP can provide. 🙂The Opcode Cache caches these intermediary Opcodes, saving that first step of reading all that PHP text, syntax checking it, and “compiling” it.
Opcode Cache does not cache text files, CSS files, DB queries or other things.
But if you change a link to CSS in a direct PHP file, or make other changes in a PHP file, there can be an up to 60 second delay before the link-change is visible. Before the file timestamp is checked and it figures out that the Opcode cache needs updating.
If you make CSS changes (changes in CSS files) on a production site, you have worse problems, since CSS files are typically set up to cache long-term on the User’s workstation. To stop it from reloading CSS and images over and over.
To see a change in how the site is viewed in a browser, you might have to use some browser-cache-busting methods.. (Like changing the ‘ver=’ parameter on the link.)
If you do browser cache busting by changing the ver= parameter in a PHP file, then yes, that link change could be delayed for up to 60 seconds. Not a big issue on a production site. 🙂
But that is why, on a development system, you typically set the check interval to 0. Don’t wanna wait to see changes. 🙂Posts do not make changes in PHP files, merely in the DB, and so are not affected by this setting at all.
In older PHP versions we used Zend, APC (Alternate PHP Cache), or other Opcode caches., which might also support other things. In PHP 7, the Opcode (Zend) Cache is a default, builtin thing, and PHP7 no longer support APC at all.
That’s why we now have APCu (APC-user cache), which is APC without the Opcode caching, but still providing User-data caching.I use APCu for caching DB queries, page caching, and many other mysterious things. 🙂
And if WordPress sees that APC/APCu is present, it will use it for transient and db caching. Saves away all the goober DB queries to the options table for all the “transient” data and options all of WordPress and many plugins use. The data is sitting in APC/APCu’s shared memory cache instead.I don’t think the Dashboard page updates/polls. Did not check.
But it is simple. If the parameter to the referrer link was WordfenceSecOpt, then you had a browser Tab active on the Options page.
Yes, setting the Update Interval will affect both the Live Traffic page AND the Options page. It will set the polling frequency to whatever number of seconds you enter there.
But notice, that many other places in WordPress does these kinds of polling/updates. To keep page current and to keep you logged in.
Go to the User (mgmt) page for example, and it polls as well. Except I think they poll every 5 seconds or so.That’s the PHP default.
The actual “default” set locally can be different, depending on the hosting setup. Since a long update frequency can make changes in PHP files seem to not work (show up delayed), some or many hosting environments set it to 0, because that stops the support calls. 🙂Mine was ‘0’ before I changed it to ’60’. 🙂
You would see your local ‘default’, if you removed that setting again, and then looked in the PHPinfo to see what it was before you changed it.
From your IP, this happens when you leave your browser/browser-tab sitting open on the WordFence Options page. It polls back to the web-site checking every 2 seconds.
Close that browser window/Tab, and it stops. 🙂
Same thing if you left a tab open (and active) on the Live Traffic page, except the option would be ‘WordfenceActivity’, rather than ‘WordfenceSecOpt’.
Currently the only links in the email is to wordpress.org, which of course could be spoofed, but would not give anyone YOUR site’s login/password.
However, if a link to YOUR site was added to the WordFence emails, knowing just your email address and your site, one could easily create a spoof-site that presents a login that look’s exactly like it would coming from your site. Then they simply send you an email that looks exactly like a “Problems found on YOURSITE” WordFence email.
You click the link, see the WP login (from what looks like your site, except if you studied the domain-name closely), you type in your admin/password on the spoof-site, and they then redirect you back to your REAL site..
If you get another login-page, which would not likely happen, you think “Shoot, must have mistyped” and do it again.Phishing accomplished. They have your admin-login and password. Ready for infection of your site and other abuse.
I agree with @wfyann & Co.. No links to the web-site in the email. It would be seriously ripe for abuse across every site with WordFence installed.
NEVER click on links in emails unless you love infections and viruses. 🙂
Opcache also definitely helps with WordFence.
My Opcache hit files are by far WordFence files, with wfIPWhitelist.php being the top one, and about another dozen+ toppers being WF files as well..
It certainly helps having WordFence “pre-interpreted” and sitting in the cache. 🙂
BTW, on a production site, you might want to try ‘opcache.revalidate_freq=60’ as well.
Stops the caching from having to check timestamps on non-changing files every time, just to check if the cached file must be updated.The default of ‘0’ makes it check timestamps on files all the time. Good for development, but quite unnecessary for a stable production system.
Forum: Plugins
In reply to: [Pods - Custom Content Types and Fields] Linking to Next and Previous PodsI think that the main thing to learn immediately from what the query looks like, is that there is no Pods involvement at all, except for Pods having set the ‘post_type’ to something other than ‘post’, when the post was created.
Since the query only looks for a post with the same post type (whatever post type you have on the page) and a datetime less or larger than current post, there is no real Pods involvement at all. It only looks in your posts table.
More importantly, if you DO NOT find these queries on the debug page, that means that it did not even try.. The only thing that theoretically could make that happen, is if get_adjacent_post short-circuits itself because it’s initial ‘get_post()’ failed.
In other words, it cannot see what the current post actually is, and so has nothing to compare to. If that happens, you have learned a lot. 🙂Please let us know what these queries look like when you find them.
For future brain-caching. 🙂Forum: Plugins
In reply to: [Pods - Custom Content Types and Fields] Linking to Next and Previous PodsInstall the “Debug Bar” plugin.. Set it to show in your admin bar.
Turn on your Admin Bar, if not already, and then go view a page that is failing to show links. Then click on the “Debug” in the admin bar, and select “Queries”.That will give you a page showing which DB queries were run, and you should find exactly what it is doing, so you can try the queries by hand.
In the debug page with the gazillion of queries WordPress unfortunately runs, hit Ctrl-F (search) and search for p.ID. (few or just one query look only to find ‘p.ID’).
The resulting query (for previous) will look something like this:
SELECT p.ID FROM YOUR-POST-TABLE AS p WHERE p.post_date < '2017-02-03 12:33:46' AND p.post_type = 'YOUR_POST-TYPE' AND ( p.post_status = 'publish' OR p.post_status = 'private' ) ORDER BY p.post_date DESC LIMIT 1The (“OR p.post_status = ‘private'”) is only there if you look at the page when logged in and you have the user-rights to read private posts..
Forum: Plugins
In reply to: [Pods - Custom Content Types and Fields] Linking to Next and Previous PodsBTW, Jim.. The Theme does not display “nothing”.. As I mentioned, if you do a view source, the NAV html code is there. But the link locations are simply empty, because nothing is returned from WP.. The theme has no way of knowing that the WP functions returning nothing is actually wrong, since that is also the result if a post has no previous or no next. 🙂
If you only had one post in a post_type, both previous and next would always be empty. No way to see that as a failure that a theme would want to report to a visitor. 🙂
Forum: Plugins
In reply to: [Pods - Custom Content Types and Fields] Linking to Next and Previous PodsIf we ignore their obscure capabilities, such as filtering on specific taxonomies (which Septera does not), or separating between what to show logged-in users versus anonymous, the WordPress get_(next/previous)_post_link functions (which work using get_adjacent_post()) are quite simplistic.
The query run by get_adjacent_post() is merely something like “SELECT p.Id WHERE p.post_date OPERATOR CURRENT_POST’s_DATE AND p.post_type = CURRENT_POST’S_TYPE”
Meaning that it looks for a post_type equal to the current post’s post_type, and a post_date that is OPERATOR (‘<‘ or ‘>’) different fromthe current posts time-stamp. Assuming that all these posts were not bulk-loaded with the same exact datetime-stamp (to the second), they should be found. 🙂 It will not find posts if all their time-stamps are equal. 🙂
Other than that, the only thing I can see that can short-circuit this, is if the WordPress get_post(), which is used to find the WP current post at the very beginning, fails. If it cannot see a current post, then it fails. Nothing to compare to.
Hard to debug with a database one cannot see. 🙂
Forum: Plugins
In reply to: [Pods - Custom Content Types and Fields] Linking to Next and Previous PodsIt is not the theme. Septera does it the same as any other.
Looking at his page source, the link locations and mark-up are there from the theme, except that the WP functions previous_post_link() and next_post_link() are returning nothing. So no links show up.It is a WordPress thing, as WordPress is not seeing these posts as related in a next/previous kinda way.
@jhabdas, You mentioned that one post type is hierarchical? Which one?