Wordfence On Multitheme

Of additional note this might be a nice feature to implement as pretty much all the cache app’s that are page level .vs. object cache dont handle multitheme installs. Wordfence normally puts in an action event for theme switch that clears the cache. Instead, make that optional.

For multi-theme simply take a look at get_current_theme() which is available at the cache plugin runtime. Ammend or append the the theme name to saved / recalled cache file names/dirs.

If you could point me at the function / direction as to where Falcon reads from the cache would be appreciated.

I am also curious as to why (I am not an ultra experienced WP Dev) cache is only available to non logged in users. Why not to front end logged in users too?

Falcon uses the .htaccess file in the root of your site, to load cached pages before WordPress even begins. When a visitor requests a page, the web server first checks .htaccess, and using Falcon’s code in that file, if the page was already cached, it is served to the visitor immediately.

You mentioned in the other post that you might be able to use a cookie on these visits — if you do, you can use Falcon’s “Cache Exclusions” (with the “Cookie Name Contains” option) to tell Falcon not to serve cached pages to users with that cookie:
https://docs.wordfence.com/en/Falcon_Cache#Cache_Exclusions

The only difficulty would be that users won’t have the cookie on their first pageview — if you plan to have a link or button that will set the cookie from any page on the regular view of the site, the cache exclusions should work for all future pageviews for that user. (Of course, you may also need a way to delete the cookie, if someone needs to switch back to the main view.)

I wouldn’t recommend editing the Wordfence plugin files, though — your changes would be lost any time the plugin is updated. I’m not sure why the doNotCache() function isn’t working for you — the cache isn’t written until a page is ready to send to the user, so it is usually ok to use it in themes. I haven’t worked on multi-theme sites before, though.

Cache files aren’t saved when a user is logged in, because they often contain information specific to that user, including the WP Admin bar, which contains the username and other information. A lot of plugins also include user-specific information or information that may change on each pageview.

I can pass your suggestion about multitheme compatibility on to the dev team — I can’t promise that every suggestion we get will make it into a release, or when that might be, but every suggestion we get is evaluated carefully and considered seriously. We value the input we get from our customers. A member of our dev team may or may not reach out to you here to ask for more detail. Thank you for helping to make Wordfence great.

Thanks for the response Matt.

I went with the theme name conditional rather than a cookie because a cookie can be deleted by the user. So, they hit the handicapped site. Remove the cookie from their browser. Reload the page and bam. Problem.

Or even bots coming in can cause issue with cookies.

Does explain why I couldnt find any output code LOL.

I will take a look at htaccess. Perhaps I can do something with that or find a way to add to the url of the handicapped theme dynamically, like a theme slug or something.

Working with .htaccess can be tough when plugins are also updating it at times, but it might be all you can do.

Another option to consider might be to use a single theme, but find a way to change only the css of the site, similar to making a responsive theme that works on desktop and mobile browsers — that way, both types of visitors could benefit from the cached files, and it may be more compatible with other plugins as well. Depending on how the themes are built, this may be a lot of work, though.

I hear ya.

Unfortunately the requirement is for both a rich content presentation and for a WCAG compatible one for those with handicaps. Literally all themes for WP dont meet WCAG 2.0 and some barely 1.0.

The way WP handles widgets is just completely brain dead. No other way to explain it. Looks like a 10th grader thought it out. Remarkably, just deleting a theme results in the database left with garbage in it breaking every rule of DB engineering since 1980 literally.

In respect to the plugins, ya… People have no idea. Four out of 9 or 10 plugins I have tried and then run HP’s vulnerability scanner against have issues.

Thats what happens when dev’s ignore what API is there and the API is so very disorganized and linear. But, is what it is.

I made a new theme switcher and it seems to help. The one I was using did a theme switch rather than a hack/short circuit. So if one switched the backend switched as well. That caused the widget code to start loosing referential integrity best I can tell.

Now, as long as the backend theme is the rich content theme selected all goes ok. When doing work on the handicapped one just need clear the cache etc. or take the site offline for maintaining. The Handicapped side really doesnt need cache, its very fast as is because its minimal. Few tweaks, font sizer, contrast control, WCAG ready menu, skip links etc and video that can play as audio only, just a hack.

I will toy around with a playground copy of the site and see what I can make happen. If I end up with anything significant for Falcon I will pass it along to you and build it out as a plugin for you or something.

I might try short circuit Falcon as well so when a user is logged in falcon doesnt load up and instead an object cache kicks in.

Will do what time affords, I still have a ways to go on the build.

Ok, well good luck on the rest of the build! If you can’t get it working well with Falcon, you could also try the basic caching option, which still gives a decent performance increase.

Hi Matt,

Well, the basic option I dont think will handle things. The site is sitting on a shared host with SSD drives. That helps. Should all go well then it will probably end up on a dedicated machine. If it were “up to me” it would have sat on a dedicated dual core elder server with me coaxing the host firm into putting a 1GB SSD into it which I’d mail to them.

When I saw Security plus Cache all in one that looked the best option. Both theme’s really perform well in as far as start to exit, again, SSD helps move things along.

One thing I noticed is alot of plugin authors seem to care less about ram usage. PHP in its own right is piggish enough by nature but lots of them load up assets not ever used in front end. Oye.

Before I entered into this pro-bono job I was working on yet another framework for theme’s thats all OOP with a very lightweight fast API. Converted Twenty Thirteen to it and it had a much lighter footprint and was considerably faster.

Wordfence has definitely given me some ideas in how to up that considerable again.

Falcon is definitely working on the rich content theme and not on the handicapped which is fine, as I said, really doesnt need to. Only quirk as I said is that the rich content theme need be selected in the WP admin backend as the current theme. Either way now its not orphaning sidebars and thus making widgets references a mess in the DB.

I went in and hand cleaned the database which is fun with serialized data (arrays).

If I had the time on hand I’d just slap a utility together to so everyone could do that since its been an ongoing issue for apparently years now.

What should be happening is on a theme context switch the prior theme’s option ID for its entry be saved in another record. If the user deletes the theme it was associated with the options also are deleted. If they re-enable it then its reversed.

Widgets should all have their own instances .vs. what apparently happens now. I understand that if a person wants try a theme its nice to have their menu system and widgets etc appear. Even that could be done (via a faux create on the fly instance(s)) with perhaps even a temporary to permanent ability. But to just disregard database integrity for sake of “this way is easy” for “users sake” is just well.. Bad engineering. Whilst I have not went through the sidebar / widget code to any large extent it “appears” as though the sidebar list is traversed on page views. So orphaned sidebars are munching time but I might be wrong on that.