1. 
   Scott Wendling
   New Member

   I'm running Wordpress MU 2.8.4a
   WP Ecommerce: 3.7.4
   I have made the modifications found here:
   http://www.instinct.co.nz/forums/topic.php?id=6341
   That allowed the files to be created.

   Then I started setting things up and I went to:
   settings>presentation the box that says:
   "Theme Customisation
   Your theme files have not been moved. Until your theme files have been moved, we have disabled automatic upgrades.

   Click here to Move your files to a safe place"

   I clicked to move the files, then it created the copy of the theme files in the wp-content/blogs.dir/x/files/wpsc folder where x is the blog id.

   Before I made this change product thumbs were showing up correctly. After the change they are all stuck in the upper left corner. Another issue that coincided with this is the "more details" expanded information. It worked fine previously, now it stays expanded.

   When I went in to dig around I found I could not access the files even though they were 777. I contacted my host and they changed the ownership so I could access them. Since then I have attempted to place the compatibility.css in the wp-content/blogs.dir/x/files/wpsc/themes folder hoping that would do it, but it has not.

   I've spent a ton of time on this and it's driving me bonkers. If anyone has any advice that would help please give freely.

   The site in question:
   http://mikemayer.comoblogs.com/products-page/

   Posted 12 months ago #
2. 

   Trusted

   shayne
   Resident Expert

   WP Ecommerce 3.7.5 should be out later today/tonight depending what time zone you're in.

   I believe this will address the issue you're having.

   If you need to contact me to get me login info, you can do that here:
   http://www.shaynesanderson.com

   Posted 12 months ago #
3. 
   Scott Wendling
   New Member

   Thanks shayne. I hope it does, told my client I would be finished by the weekend. Don't want to have to ditch this plugin for a less featured one at the last minute if I can avoid it.

   Posted 12 months ago #
4. 
   tom
   Resident Expert

   Your server seems to be serving the CSS file with a mime type of "image/33", for a css file to work it must be served with a mime type of text/css. If I download it and view it with a text editor, I find the contents to be correct, though.

   This is probably because the URL to the CSS file is http://mikemayer.com/files/wpsc/themes/default/default.css?ver=3.7.33
   It looks to me like your web server is detecting the ".33" at the end of the URL and is then treating the file as an image, this is incorrect behaviour on the part of the web server.

   I just tried editing some files to see if it was possible to fix this with code, however, if I remove my code to provide the version number at the end of the CSS files, WordPress then inserts its version number instead, which will result in the same problem.

   People have requested that we use the wp_enqueue_script and wp_enqueue_style functions to add our CSS and JavaScript in, so we can't really switch back to the old method of inserting them.

   I think the best solution would be for you to contact your hosting provider about this, it seems to me with that this is a problem with their server configuration.

   Posted 12 months ago #
5. 
   Scott Wendling
   New Member

   Thanks a lot Tom. I really appreciate you digging into that. I'll contact my host right away and see if we can get the issue resolved from their end.

   Posted 12 months ago #
6. 
   Scott Wendling
   New Member

   Tom- I spoke to my host which is Psek and I got this in response to the support ticket. In the ticket I referenced this page and detailed the problem. Here is their response:

   "Hello,

   this issue has nothing to do with the server setup. Please check this simple test URL (we've created sample.css in your public_html):

   http://mikemayer.com/sample.css?ver=3.7.33

   As you can see server gives correct mime type for any existing .css file even with ?ver=3.7.33 at the end. Your CSS url http://mikemayer.com/files/wpsc/themes/default/default.css?ver=3.7.33 has no real CSS file so it's being parsed by your PHP scripts according to mod_rewrite rules you have. So your PHP scripts give wrong mime type for that URL but not the web-server. Please check your PHP scripts or contact their developers.

   Thanks
   --
   Alex"

   Does this help flush out the issue any more? Since it worked before I moved the files to a safe place and the CSS broke after moving i had assumed it wasn't calling the correct file or couldn't find it which is why I had tried copying the compatibility.css into the blogdir theme trunk. Is there a modification I can make in the CSS so it calls the right file?

   In the short term: Is there a way to simply revert the change? As in move the files back to an unsafe place where they work until I can get this troubleshooting done on a test server? If not then I am left with abandoning this plugin for now or recreating the whole site over on a new blog and simply not moving the files to a safe place. Any further advice on this? Thank you for your help thus far.

   Posted 12 months ago #
7. 
   Scott Wendling
   New Member

   Since the test post with the .33 on the end works, and if I simply remove the ?ver=3.7.33 bit from the file path it works, this leads me to think it may be a mod_rewrite problem. Would you agree or not? If so, what can I change in mod_rewrite that would allow this to properly execute?

   Posted 12 months ago #
8. 
   sarky1
   New Member

   Hello,

   I have had the exact same problem, when using Wordpress MU just like Scott.

   The reason this happens is because of the rewriting that is required by MU, I have made a simple change to be able to get around this for the time being and that is parse .css at the end of this link. i.e

   File: wp-content/plugins/wp-e-commerce/wpsc-includes/theme.functions.php
   Line 90,
   Before: wp_enqueue_style( \'wpsc-theme-css\', $theme_url, false, $version_identifier, \'all\');
   After: wp_enqueue_style( \'wpsc-theme-css\', $theme_url, false, $version_identifier . \'.css\', \'all\');

   Nasty I know, but was the quick work around that cleaned up everything for me.

   Regards,
   Josh Haywood

   Posted 10 months ago #
9. 
   ithackermike
   New Member

   sarky1,

   You're a genius. U just brought an end to 6 hours of banging my head against the wall.

   -mike

   Posted 7 months ago #
10. 
    arandomdan
    New Member

    This should really be fixed because I had this problem with the latest versions of Wordpress MU and WP e-Commerce.

    Posted 5 months ago #

RSS feed for this topic

Reply

You must log in to post.