Forum Replies Created
-
AuthorPosts
-
dcipherPost count: 66This reply has been marked as private.dcipherPost count: 66
Hi Suman,
I wanting to revive this thread because I don’t quite think we’re entirely aligned with the requirements. I’ll try to reiterate the specifics of my question.
Our site is only accessible through CloudFront. When you configure CloudFront, you also need to configure custom behaviours on how the CloudFront CDN handles specific paths.
Right now, I have a large list of custom behaviours including a few for the /wp-includes and /wp-content paths, configured in CloudFront which handle assets from these directories in a certain way.
Now, for example, HMWP is rewriting my wp-includes directory to /lib and my wp-content directory to /content. The question that I need answered is: Do I need to create custom behaviours in CloudFront that point to /lib and /content INSTEAD of the actual path of /wp-includes and /wp-content?
dcipherPost count: 66This reply has been marked as private.dcipherPost count: 66This reply has been marked as private.dcipherPost count: 66This reply has been marked as private.dcipherPost count: 66This reply has been marked as private.dcipherPost count: 66Hi Suman,
Yes I am using AWS however my instance is configured to use htaccess so I can confirm that mod_rewrite and htaccess are working.
I’m aware that HMWP only uses the the htaccess file to rewrite locations of files, however I need clarity on how CloudFront handles this.
Right now as an example, I have custom cacheing behaviours configured in CloudFront for static assets being served from wp-content/* directory, amongst others. Because a client’s browser accessing the site (through CloudFront) doesn’t technically see the URL structure because of how HMWP rewrites it, I want to know if CloudFront’s custom cacheing behaviours for those static assets still applies OR would I need to create additional behaviours now in CloudFront which reference the newly rewritten value that HMWP adds?
So current behaviour specifies wp-content/* as the origin path;
HMWP rewrites wp-content to ‘other’;
Do I need to create a new behaviour in CloudFront for origin path other/*?OR, should things just work!
Hope that’s clear.
dcipherPost count: 66Thanks Suman.
You answered my question.
Much appreciated.
dcipherPost count: 66Thanks Suman.
Just one final question, should I decide to use CloudFront as a complete reverse-proxy for my site (essentially have our primary website URL point to the CDN to serve ALL resources) then I assume that I should at that point configure the CDN settings in HMWP right?
dcipherPost count: 66Hi Suman,
Things appear to be running much better now since we deployed a clean HMWP configuration.
Appreciate your willingness to assist, I’ll go on and close the case for the time being.
dcipherPost count: 66Hi Suman,
Apologies for that, I have restored the original htaccess file and disabled HMWP for the moment just monitor how things are progressing so accessing the site probably wouldn’t tell you much. I plan to reinstate HMWP today with a fresh configuration and test the site again to see if the 500 errors occur.
I will update this ticket in the next 24-48 hours and provide further access details if the error appears again.
Many thanks.
dcipherPost count: 66This reply has been marked as private.dcipherPost count: 66This reply has been marked as private.March 21, 2019 at 10:43 pm in reply to: General Questions about Full Hide and Plugin Hide features #25902dcipherPost count: 66Thanks Suman, appreciate the reply.
March 20, 2019 at 5:39 am in reply to: General Questions about Full Hide and Plugin Hide features #25872dcipherPost count: 66Furthermore, could you please also explain the ‘Enable REST API, Enable Authors URL…. etc..’ options found in the permalinks tab?
If I select the ‘Disable REST API’ option, does this in fact disable the wordpress REST API completely or just the way your plugin interacts with it? (same question obviously applies to the other options available within this section).
Many thanks.
-
AuthorPosts