[Plugin: Yet Another Related Posts Plugin] CSS/JS paths on admin page broken

  • Resolved Anonymous User 92042

    (@anonymized-92042)


    14 years, 4 months ago

    I have YARPP installed and operating fine on my local OS X development machine, but upon deployment to production, I found that some admin functionality is broken due to bad CSS/JS paths. The plugin operates just fine, in that the related posts are found and displayed properly. This problem is limited to the admin page.

    None of the YARPP CSS or JavaScript is loading, which means the popup descriptions of some options doesn’t work, nor can I turn off the BlogGlue add in Screen Options.

    Looking at the source I find that all the paths inserted by the plugin look like this (paths anonymized):

    <link rel='stylesheet' id='yarpp_options-css' href='https://www.example.com/content/plugins/home/username/web/example.com/releases/20120204011521/public/content/plugins/yet-another-related-posts-plugin/options.css?ver=3.4.3' type='text/css' media='all' />

    As you can see, the full filesystem path is being returned instead of the URL path. This happens to all paths inserted by the plugin.

    The problem seems to be related to use of __FILE__ in plugins_url() in class-admin.php. That’s a WP function, not yours, but your plugin is the only one I’ve ever seen this problem with, so I’m not sure what’s going on there.

    I’m using the latest version of both this plugin and WordPress itself. My dev environment, which works fine is running OS X 10.7.2 with Apache 2.2.20 and PHP 5.3.6. My production server is running Ubuntu 11.10 with Apache 2.2.20 and PHP 5.3.6. All Apache and PHP packages are the system defaults, nothing custom.

    Thanks.

    http://ww.wp.xz.cn/extend/plugins/yet-another-related-posts-plugin/

Viewing 6 replies - 1 through 6 (of 6 total)
  • jeffgran

    (@jeffgran)

    14 years, 3 months ago

    +1

    I have this exact same problem. Works locally, but after deploying to production, the JS and CSS have mangled paths.

    I thought maybe it was a thing where some absolute path is stored in the database but that doesn’t seem to be the case. Don’t know what’s causing it.

    jeffgran

    (@jeffgran)

    14 years, 3 months ago

    Looks like this comes down to a problem with PHP’s __FILE__, which resolves symlinks and gives the real absolute path of the file instead of the symlinked path of the file. That in turn causes the plugins_url() and related functions to fail in the mode described above.

    See bug report and discussion below:

    http://core.trac.ww.wp.xz.cn/ticket/16953

    mitcho (Michael Yoshitaka Erlewine)

    (@mitchoyoshitaka)

    14 years, 3 months ago

    I’m a little confused… do you have symlinks in the path to YARPP in the deployment environment?

    jeffgran

    (@jeffgran)

    14 years, 3 months ago

    Yes. My environment is like this:

    WordPress lives at /var/www/mysite.com/blog/

    The file /var/www/mysite.com/blog/wp-content is a symlink to /var/www/mysite.com/releases/20120225/wp-content.

    So when I deploy a new theme/plugin/etc release, I put it in a new release folder and just change the wp-content symlink to point to the new one.

    When I view the admin page and look at the source, I see the URL for the JS file is like "http://www.mysite.com/blog/wp-content/plugins/var/www/mysite.com/releases/20120225/wp-content/plugins/yet-another-related-posts-plugin/js/options.js?ver=3.4.3".

    To be clear, this isn’t just a problem with YARPP, but a problem with any plugin that uses the plugins_url() function (and its related functions, like plugins_dir_url()).

    Thread Starter Anonymous User 92042

    (@anonymized-92042)

    14 years, 3 months ago

    I have a symlink not to YARRP but to the web site’s document root. I deploy with Capistrano, which keep previous deployments of the site so you can easily roll back changes.

    So the filesystem path you see above:
    /home/username/web/example.com/releases/20120204011521/public

    Is symlinked as:
    /home/username/web/example.com/current/public

    The latter is the path in my web server config. The current directory is a symlink to the latest deployment, which is actually in the datestamped releases/20120204011521 directory.

    I’ve been running a handful of WordPress sites this way for years and this is the first time I’ve come across this issue.

    mitcho (Michael Yoshitaka Erlewine)

    (@mitchoyoshitaka)

    13 years, 9 months ago

    Indeed, this is a general problem with plugins_url() and related functions, which is something I’d love to see get solved in general. Here’s the core ticket for this type of issue: https://core.trac.ww.wp.xz.cn/ticket/16953

Viewing 6 replies - 1 through 6 (of 6 total)

The topic ‘[Plugin: Yet Another Related Posts Plugin] CSS/JS paths on admin page broken’ is closed to new replies.