WordPress proxy #2632
Comments
|
Timing-Allow-Origin: * header is missing. Also, add public to cache-control header for consistency. |
|
Added Timing-Allow-Origin and CORS |
|
there might be broken img/font/etc issue. which use relative img/font path in css file. |
|
It depends but technically relative paths should work just fine. |
|
|
|
It's because right now only css|js is permitted. |
|
sorry, i forgot beta status. |
|
I don't see why to not permit commonly used files :) images, fonts, css, js. When we made the nginx config we wanted to try with these two file types first. |
|
All font files are now allowed too. Keep up the testing :) |
|
How about themes? |
|
Also, are you going to update the jsDelivr WordPress plugin to use this feature? |
From a user-performance point of view, comes to a certain point where it is better not to host everything outsite the originating URL. |
|
@tomByrer Can you give an example? Basically this also means using a CDN for WordPress (like maxcdn, cloudfront) with common setup like wp-super-cache and w3tc hurts performance. |
I dont plan hosting them. Most people buy their themes from third-party markets, so there is no way to proxy everything.
If I find an affordable freelancer to do that then yes |
|
@pnommensen Each browser only has a few 'spare' HTTP connections for serving outside Originating Hostname. 4-11 last I looked. Browsers have 6-8 max connections for the originating, so if the only file served from there is the Really important for WP sites, since most have YMMV, best to test. |
|
Even if jsDelivr serves 100% of the plugin files it will never be the only hostname for the website. Dont forget the theme files, images, other crap they add. So the problem you are describing will never happen. I can only see benefits from the speed of our CDN and parallelization across multiple hostnames (jsDelivr+website domain) |
Yes, thus my "don't host the entire theme on a CDN" caution. You're right, when it comes to WP, usually not a worry; Orig Hostname HTTPs are usually saturated.
That was the point of my lightning talk at Pivotal Labs. :) Though hosting an essential JS or CSS might be faster on Orig Host vs CDN; really it is a last-minute test & tweak. |
|
This is such a great feature, I'm going to add it to 3.9 :) how long does it take for your proxy to detect a new version on the repository? You guys rock. I will recommend that we use this at my day job at the City University of New York, for our plugins ;) |
|
Please dont push it to production yet. I want to make 100% sure that nothing will break if used live :) There is nothing to detect, once you tag a version and it appears on WordPress its automatically available on jsDelivr. So its instant, no waiting at all. Test it out if you can and let me know if you find any issues. |
|
Okay cool, I'll just test it locally for now then. Getting recognition from WP would be huge :) |
|
It looks stable enough to me :) I've been testing it under various scenarios, and so far it's working as expected. Let me know when you think it's ready for prime time! I can't wait to implement it in Slimstat. |
|
what do you think of changing dir name to |
|
Why do you say that? And why anyone needs to guess anything, The devs will read what it is on our docs and the users that will see it on their source code are not our problem (although most will understand what it is) Sorry I just dont follow your logic :) |
|
I vote for leaving it as 'wp' ;) Shorter and more intuitive. |
|
there is already |
|
Please ping me when you think this is ready for prime time! |
|
Honestly I dont see any issues, I was just waiting for people to report their problems. I guess you can push this live and let me know how it goes :) |
|
Awesome! Now the hard part is to create a page on our new website explaining this new feature. |
|
Are we going to use the github wiki? |
|
I was talking about this jsdelivr/www.jsdelivr.com#28 |
|
I just released version 3.9.2 to fix a bug discovered by one of our users, and everything worked out perfectly right away. This is really a killer app! |
|
@getusedtoit Awesome! Unfortunately very few devs will know about this because we suck at promoting new features :p |
|
I know! Let's just put a huge pop up on jsdelivr.com! There's a 100% chance if people noticing! There's also a 100% chance of annoying users! :-P On Wed, Jan 7, 2015 at 4:19 AM, Dmitriy Akulov notifications@github.com
|
|
wow I just had that idea looking at my sites PageSpeed audits. Glad you did it ! Keep it up :) |
|
Hi guys, I have a quick question about this functionality. I see that the following URL is working as expected: http://cdn.jsdelivr.net/wp/wp-slimstat/trunk/wp-slimstat.js Is it safe to assume that it will be available in the foreseeable future just like the "tags" version? I usually push the latest stable both as a tag and in trunk (since I use github for development), and by using this trick, I wouldn't have to worry about including the version number in the URL anymore. Thank you in advance! |
|
Yeah, should work great :) Patrick Nommensen
|
|
👍 |
|
There is an issue with caching, though. I believe the CDNs, origin, and browsers cache a copy of it for an indefinite amount of time. I think it is necessary to include the version number in the tag version for cache-busting. On Sun, Feb 1, 2015 at 11:41 AM, Patrick Nommensen
|
|
Good point! |
|
Yes, dont use trunk because it will always show older versions. You can use some wordpress variable with the plugin's version to automate the process. |
|
Amazing feature, well done! |
|
Hi guys, we pushed an update to our plugin, however the CDN is serving the old file for some reason: https://plugins.trac.wordpress.org/browser/wp-slimstat/trunk/wp-slimstat.min.js versus http://cdn.jsdelivr.net/wp/wp-slimstat/trunk/wp-slimstat.min.js Could you please look into this? |
|
Dont use the trunk, use the tags. Trunk gets cached and needs purging and its not recommended to use it. This is much better: You can use a wp function to automatically get the plugin's version and insert it into URLs, fully automated. P.S. I purged the trunk as well. |
|
Hi jimaek, thank you for your prompt response. The reason why I'm using trunk is that many of our users use caching plugins for WordPress. Which means that the source code of the page is "frozen" for days. When we release a new update, the URL in the cached version of the page will still point to the previous one, thus breaking the functionality for all those users. We've tried to warn our users by displaying messages that invite them to clear their WP cache, but many times people end up submitting a support request anyway, lamenting that the tracker is not working. Our goal was to minimize those requests to our support team, by finding a way to keep the URL always the same. What solution could be implemented to address this issue? (other than telling our users to clear their cache every time they upgrade). Thank you again! |
|
Have you tried something like this http://wordpress.stackexchange.com/questions/7112/w3-total-cache-cache-refresh-programmatically ? When you update plugins W3 Total Cache will notify the user as well that he needs to clear his cache. Anyway if none of this solutions work then shoot me an email and I will give you access to our purging API. You will be able to use trunk and purge when you release a new version |
|
Interesting link, thank you for sharing. Unfortunately not everybody uses W3. Some of our users use SuperCache, others use HyperCache, etc. I wish it was that easy :( How much work would it be to have trunk purged let's say once every 2 hours. If that doesn't work, I'm okay with purging it through the API. Let me know what works best for you :) |
|
You can set a cronjob on your server and ping our API to purge the cache whenever you want. But if you purge every 2 hours then the CDN will get much slower because every 2 hours all 70 nodes will need to re-cache the file. |
|
You're right, and I don't want that :) I'll just do it manually whenever I release an update. That works for me. I'll send you a private message. Again, thank you so much for this service and for being on top of things! |
|
np :) |
|
I think most caching plugins automatically clear the page cache when a Also, there is the possibility that some lazy/ignorant people don't update
|
|
Setting as trunk would cause some issues with non updated installs. Let's say you introduce new code in wp-slimstat.min.js that is not backwards compatible - it will break any installs running on previous versions of the plugin (since the plugin always requests the latest js file). |
|
@hubdotcom Good point. Major changes to the tracker are quite rare, I must say. Most of the time, we tweak the code to fix bugs in the JS code, which means that even people who don't update Slimstat, will get the new tracking script automatically. And of course, those who have their own rationale for not wanting to upgrade the plugin, can always turn the CDN setting off, and serve the script from their website ;) |
|
Fair enough - just using this for the tracking script makes perfect sense! |
A new feature that I always wanted to have is finally here.
We can now automatically proxy any file from the WordPress repository. All you have to do is specify the name and version.
For example:
http://cdn.jsdelivr.net/wp/1000eb/tags/3.3.1/javascripts/admin.jshttp://cdn.jsdelivr.net/wp/wp-slimstat/tags/3.8.5/wp-slimstat.jsThis feature can simplify the integration of jsDelivr for all developers. Now its ridiculously easy to add a CDN option to any plugin.
It works by proxying http://plugins.svn.wordpress.org/ and adding the correct content-type headers. So WordPress takes care of the security audit and adding new versions.
The proxy for now allows only css,js and font files to be proxied.
Please test it out and let me know what you think. Are there any bugs? Any features missing?
@getusedtoit As a WP dev what do you think?
The text was updated successfully, but these errors were encountered: