Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The uploads folder does not always reside within get_site_url(). #79

Closed
3 tasks done
hackles opened this issue Mar 8, 2019 · 2 comments
Closed
3 tasks done

The uploads folder does not always reside within get_site_url(). #79

hackles opened this issue Mar 8, 2019 · 2 comments
Assignees
Labels
released Indicate that an issue has been resolved and released in a particular version of the product.

Comments

@hackles
Copy link

hackles commented Mar 8, 2019

Describe the bug
The uploads folder does not always reside within get_site_url(). In cases where it doesn't, URL replacement does not work as expected.

To Reproduce
Steps to reproduce the behavior:

  1. Install WordPress in a subdirectory, such as Bedrock
  2. Install and activate Optimole
  3. Image rewrites will not work.

Please note that there might be other scenarios in which get_site_url() would be incorrect, such as defining UPLOADS or WP_CONTENT or WP_CONTENT_URL.

Expected behavior
Image rewrites should work.

Isolating the problem (mark completed items with an [x]):

  • I have deactivated other plugins and confirmed this bug occurs when only Optimole plugin is active.
  • This bug happens with a default WordPress theme active
  • I can reproduce this bug consistently using the steps above.

WordPress Environment
WordPress Version: 5.1
Optimole Version: current development branch
PHP versions: 7.2

Resolutions
I personally was able to use get_home_url() as a drop-in replacement and It Just Works™. But other ideas might be to use WP_CONTENT_URL or some wizardry with wp_upload_dir(), depending on what sort of non-standard environments you guys wish to support.

preda-bogdan added a commit that referenced this issue Mar 11, 2019
selul added a commit that referenced this issue Mar 11, 2019
selul added a commit that referenced this issue Mar 11, 2019
@selul
Copy link
Contributor

selul commented Mar 11, 2019

@hackles nice catch, thanks a lot for reporting.

I have added the patch in the upcoming release, let me know if you spot any other issues or you have any other suggestions.

@selul selul closed this as completed in 980fcef Mar 11, 2019
selul pushed a commit that referenced this issue Mar 11, 2019
#### [Version 2.0.4](v2.0.3...v2.0.4) (2019-03-11)

* **Bug Fixes**
   * adds full compatibility with Envira gallery ([7fd618f](7fd618f))
   * compatibility with Foogallery plugin when the gallery uses lazyload too ([67991dc](67991dc))
   * compatibility with images which contains query arguments, causing broken image urls ([56108be](56108be))
   * compatibility with relative image urls ([8089610](8089610))
   * compatibility with Revolution slider, adds support for background images lazyload and exact match ([0bbd254](0bbd254))
   * compatibility with shortcode ultimate plugin ([164ba35](164ba35))
   * compatibility with Woocommerce, solving issue with zoom image on single product pages ([1692e2b](1692e2b))
   * image replacement on WordPress REST api responses ([24d191b](24d191b))
   * image url replacement on custom WordPress directory structure, fixes [#79](#79), thanks [@hackles](https://github.com/hackles) for reporting ([980fcef](980fcef))

* **Features**
   * tested up compatibility with WordPress 5.1 ([12726b6](12726b6))
   * **api:** adds filter for restricting watermark based on image source urls ([337d7fa](337d7fa))
   * **api:** adds filter to disable image replacement on a specific page/ur ([3250a8d](3250a8d))
@selul
Copy link
Contributor

selul commented Mar 11, 2019

🎉 This issue has been resolved in version 2.0.4 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

@selul selul added the released Indicate that an issue has been resolved and released in a particular version of the product. label Mar 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
released Indicate that an issue has been resolved and released in a particular version of the product.
Projects
None yet
Development

No branches or pull requests

2 participants