Not one for queueing up? Get faster support with AdRotate Pro!
The forum is checked a few times per week. With AdRotate Pro you can get answers faster using email support.
More private, more direct and usually a solution within a day! Learn more »
Thanks for your response Arnan! 🙂
Having looked into similar issues for various plugins and based on my experience researching the ways various plugins do things, I have the following to offer:
From my understanding it is fine to use
WP_CONTENT_DIR so long as you are not setting or modifying it in the plugin. For reference, you can see the way that Jetpack, WooCommerce, and Vaultpress (all Automattic plugins) make use of
WP_CONTENT_DIR. There are countless others out there that make effective (and non-destructive) use of it.
In general, the plugins that handle scenarios like this gracefully do some or all of the following:
* Most will use/set one or more path variables of their own that they use for the plugin’s purposes based on how they use it. In the case of this plugin, you might
* Check whether
ABSPATH are set and based on the determination, compare them to see if the paths are the same. Once this is done, a determination can be made on how to set the plugin’s pathing variable for use. In the case of this plugin, if
ABSPATH != WP_CONTENT_DIR then you know not to set the default value to
ABSPATH . 'wp-content/banners/' and to instead use
WP_CONTENT_DIR . 'banners/' for the default banner folder.
* It isn’t enough to simply check if
ABSPATH . 'wp-content' exists because somebody could have WP Core managed in a directory and
WP_CONTENT_DIR defined to be in a separate directory than where WP Core is managed but they did not delete the default
wp-content folder. For example, you could have
/htdocs/wp/. Even though
ABSPATH. 'wp-content' exists, it does not share the same path as
As for the nature of the
banners folder being allowed to be anywhere, you are correct that this presents an interest issue and one that I do not have a solid answer for.
I would note that while it is true that this is an issue that needs solving, it is also an issue that the plugin facilitates and makes possible by allowing this functionality. I know it would be a big change in functionality, but it seems like forcing the banners to exist inside the upload directory or inside WP_CONTENT_DIR is a far safer bet because it presents a scenario where you can assume/determine banner folder path far more easily.
Assuming that the plugin ultimately decides to continue allowing users to set their directory path however they would like, then my next best suggestion is to simply remove the requirement that the directory live inside of
ABSPATH and let the user enter the full path to the directory. An example of this would be to allow the user to input/use
/htdocs/misc/banners/ or something similar. There is no easy way to assume the docroot because even using something like $_SERVER[‘DOCUMENT_ROOT’] isn’t always reliable.
Removing the requirement that it is at
ABSPATH . $adrotate_config['banner_folder'] and simply allowing it to be
banner_folder is set by the user (via wp-admin panel) to something like
/public_html/banners/ or anything else still allows for the customizability but also gives a truer flexibility.
Hope this is helpful! If you are interested, I can get a site set up on our servers for you/us to test on. We are truly interested in resolving this issue and believe that it would benefit owners of this plugin and bring increased compatibility for essentially any WP setup/configuration.
PS: I would like to note that the WP Codex is severely out of date in many many areas. The codex should be approached/referenced with caution in all cases. I take great care to talk with developers (of WP Core and otherwise) to try and find best practices until a more up to date and better maintained codex comes along.