• Resolved bitx004

    (@bitx004)


    Hi. I am using WP Hide WordPress plugin which allows me to use alternate URL path names for wp-content & wp-includes directories for security/obscurity reasons. From my limited understanding the way the plugin works is it relies on .htaccess URL rewrite rules and tweaking of URLs in the outgoing content/generated source. (Page source modification typically occurs after after all other plugins and wordpress logic is executed.) Thus WP Hide plugin does NOT rely on the URLs found in WP_Styles or WP_Scripts but performs basic search/replace against the page output after the fact.

    As you know, FVM relies on WP_Styles & WP_Scripts for URL discovery. The URLs in WP_* use the original /wp-content/ & /wp-includes/ paths causing 404s and no capturing the css/script content. As a simple suggested solution, it would be nice if FVM would introduce a filter that allows for developers to tweak the URL prior to fetch… making integrations with other plugins possible. I would create a filter that will rewrite the URL based off WP Hide plugin helper functions.

    Something as simple as this one-liner added at the end of function fastvelocity_min_get_hurl should do the trick:

    $hurl = apply_filters('fvm_get_url', $hurl);

    Thanks!

Viewing 8 replies - 1 through 8 (of 8 total)
  • Thread Starter bitx004

    (@bitx004)

    Hey @alignak. I know it is a feature request but I would appreciate some feedback or thoughts on my suggested approach above. Do you like the suggestion or do you have an alternative? Are you willing to implement it and if so, then I would appreciate a potential timeline when to expect it?

    Currently I have the custom apply_filters hardcoded into your plugin codebase but I am hesitant to keep it long-lived.

    Thanks so much!

    Plugin Author Raul P.

    (@alignak)

    Hi, sorry the late reply, been busy recently.

    I’m not sure I understand the problem. Doesn’t FVM merge the files properly, even if you change your urls structure?

    FVM will open your files directly from the disk, or if it fails, via an http request.
    In case of the http request, it will request the real url, which should still work, as long as the file exists.

    Can you give me an example, of where is FVM failing to merge the files?

    Thread Starter bitx004

    (@bitx004)

    No worries, thank you for replying!

    That is correct, FVM is unable to merge the files properly because it is failing at the step where it fetches the contents of the CSS/JS files. FVM is trying to fetch the CSS/JS files under the original URL formats (which have been blocked) vs the new mapped URL formats created by WP Hide.

    For example, prior to configuring my WP Hide plugin, my URLs look like https://domain.com/wp-content/themes/my-theme/foo.css. With WP Hide configured, my URLs now look like https://domain.com/theme/foo.css because I mapped /wp-content/themes/my-theme/ to /theme/. (This mapping simplifies URL structure and hides ‘wp-content’ which exposes knowledge of WordPress.) In addition to the mapping, WP Hide can also block accessing the file using the original urls just in case someone wants to probe wordpress directory/files.

    When FVM attempts to fetch CSS files, it is trying to fetch using the the original URL /wp-content/themes/… path which is blocked. With a strategic filter option (e.g. fvm_get_url) in the right place, we can assist FVM by transforming/mapping the fetch URLs for these kind of scenarios.

    I hope this makes more sense. Let me know if you would like me to elaborate more.

    Thanks!

    • This reply was modified 4 years, 8 months ago by bitx004.
    Plugin Author Raul P.

    (@alignak)

    Got it, however, unless you can also rewrite what’s on WP_Styles or WP_Scripts, I don’t think FVM will be able to do that.

    We need to read from WP_Styles & WP_Scripts so we can evaluate dependencies and before/after scripts, conditional tags, etc.

    In my opinion, obfuscating wordpress is pretty pointless.
    It’s not very difficult to know that you are using it, even if you change all public file paths.

    If you must do obfuscation, I suggest having a 301 redirect from the old to the new urls… or if you really must block the original urls, you can perhaps whitelist your own server IP. FVM will only use your server public IP to request the files to itself.

    There is nothing on FVM I can do right now, to cater to this situation.

    Thread Starter bitx004

    (@bitx004)

    Thanks Raul for sharing your opinion on security thru obfuscation. There is definitely two large camps on both sides but have decided to go with it anyways… plus I get nicer URLs :). So your 301 redirect option will not “hide” the wp-based URLs but just require an extra hop.

    As for your whitelisting option, it is a good suggestion that I have not considered yet, thank you. First thing that comes to my mind is that WP Hide plugin unfortunately does not support such an option and I will have to request it on their side to block except certain IP addresses. It seems like it will be a bigger change than what I have requested from you below.

    Alternatively I was hoping that you concerned my one-liner code change which would resolve issue and introduce a (backwards-compatible) optional filter that developers can take advantage to control URLs prior to your fetch; i.e.

    $hurl = apply_filters('fvm_get_url', $hurl); added at the end of your fastvelocity_min_get_hurl function. I can take advantage of this new *feature* and rewrite the URLs using the filter hook. Please do consider it!

    Thank you very much!

    Plugin Author Raul P.

    (@alignak)

    Sure, I’ll add the filter for $hurl = apply_filters('fvm_get_url', $hurl); on the net version. Just be careful with the rewrites ??

    Thread Starter bitx004

    (@bitx004)

    You’re awesome Raul, thank you so much! I promise I will be careful :). I did a dry run with the above suggested fix and it will solve the integration problem with WP Hide.

    Thanks again.

    Plugin Author Raul P.

    (@alignak)

    FYI this was added on 2.8.1

Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘Feature Request: chance to rewrite URL’ is closed to new replies.