• Using the latest W3TC version, 0.9.2.8, I’m getting the “Source not found” error for every one of my custom file exports for my CDN (Rackspace Cloud Files), using a CNAME/subdomain to hide the ugly URL.

    All of the paths listed appear to be relative to the site address (rather than the WP address), which is at least one of the issues. All the other categories of file to upload are correctly detecting the path.

    Other than the custom file paths missing the prefixing “cms/” (which is where my WP install is located), the paths are correct and I have spot checked that they all contain the file that they should.

    I’ve got another WP instance up and running with W3TC on another cloud site so I’m at a loss as to what could be the issue since they should be both configured the same other than the domain.

    The only difference is that the first instance is using XCache for everything and the second is using Disk (for some reason, XCache threw a ton of errors on the second instance and I didn’t care enough to try and get that working).

    Any suggestions on how to debug this?

    https://www.ads-software.com/extend/plugins/w3-total-cache/

Viewing 11 replies - 1 through 11 (of 11 total)
  • I’m getting this too, or similiar.

    My paths as per the error log though are merely missing the leading slash:

    var/lib/wordpress/wp-content/themes/graphene/screenshot.png Source file not found.

    I _think_ this is related to Debian’s 2.5.1 in unstable moving to use a FHS standard for wp-content (ie. under /var), but I’m not sure.

    Robin-wedding-photographer

    (@robin-wedding-photographer)

    Dan & lingfish, did you find an answer?

    I’m having the same problem. Subscribed to Rackspace for a CDN, configured through Total Cache, everything uploads well except for the custom files, which basically means all of my plugins. So at the moment I can’t even use the CDN because of this.

    Robin-wedding-photographer

    (@robin-wedding-photographer)

    Update: I tried installing version 0.9.2.5 and there the custom files work perfectly well. So it appears that it’s something that’s gotten broken in one of the last update. I heard that versions 0.9.2.6 and 0.9.2.7 often break people’s websites, so haven’t tried them yet.

    So it’s version .5 with a security risk,
    versions .6 or .7 (not tested) with a site breaking risk,
    version .8 with custom files not working (so no plugins hosted on your CDN)
    or wait for the next version.

    Choose your poison;)

    Thread Starter Dan Rossiter

    (@danrossiter)

    Thanks for the info, Robbin-wedding. I’ll check when I’m back in the office tomorrow.

    Hi, I’ve done some work on this… will post soon, just don’t have time right now.

    Plugin Contributor Frederick Townes

    (@fredericktownes)

    @lingfis Had a report that there are issues on Debian using its default WP symlink setup. Send a support request.

    The rest: Can you submit a bug submission report through the support tab of the plugin so we can take a closer look at your issue as well?

    Robin-wedding-photographer

    (@robin-wedding-photographer)

    @frederick, how do I submit a bug submission? Do you mean just posting a message on the support tab?

    I’m having the same problem. Media files, attachments and theme files get uploaded successfully but when i try to upload the custom files i get the “source file not found” error.

    I’m using WordPress with it’s own directory and I believe the bug is this one:

    * When it searches for files it places the wp directory in the path correctly like this:

    wpdirectory/wp-content/etc/etc

    This way the total number of files is displayed correctly.

    * But when i click the Start (upload) button, for some reason it tries to upload the files without using the WP directory in the path like this:

    wp-content/etc/etc

    Can anyone help? I’ve been trying to make it work for hours.

    Thanks

    Still happening for me, and it isn’t just custom files. Did some work with the author but didn’t get far.

    @lingfish

    Is there any workaround? i was thinking to upload the files manually. how to do that?

    Nope. Especially in my case, using Rackspace CDN, I would have to use some third party uploader tool, etc etc blah blah… and then how to tell W3 to rewrite URLs appropriately, etc.

    Well, technically there is a workaround, and that’s to hack W3 code… but that will then break based on if you’re using Debian’s idea of multisite, only partially offloading to CDN (say only themes), etc. It shouldn’t be this hard.

    I’ve heard nothing more from the author, and cannot fathom why he strips the leading / off paths for upload; his filesystem level code seems to assume paths are relative, when they’re not.

    I’ve been following this bugreport, and have tried the realpath tricks with no luck as well.

    Last I got was this:

    For the other issue it seems that the symlink usage causes strlen to return different filelength than what is used with wp_content_dir path. That is the “root” path part of wp_content_dir differs from the site/docroot path. Which means a letter is dropped. You could try add -1 so the strlen looks like

    trim(substr(WP_CONTENT_DIR, strlen($site_root)-1),’/\\’);

    until a proper fix is released.

    Didn’t seem to work, universally.

Viewing 11 replies - 1 through 11 (of 11 total)
  • The topic ‘"Source file not found" for all custom files to be served from CDN.’ is closed to new replies.