By: Michal Golebiowski-Owczarek, Felix Nagel, and the jQuery team

Editor’s Note: the following blog post was originally published to the OpenJS Foundation Blog.

jQuery maintainers are continuing to modernize its overall project that still is one of the most widely deployed JavaScript libraries today. The team announced that the cross-platform jQuery Mobile project under its umbrella will be fully deprecated as of October 7, 2021. New technologies for mobile app development have evolved since this project was launched in 2010, so we’re encouraging developers to plan for this jQuery Mobile transition.

Please note that:

• The Download Builder will remain available.
• Mobile 1.4 is not compatible with the latest jQuery Core.
• Issues will be turned off. Please report critical security bugs via email to security@jquery.com. 

Celebrating jQuery Mobile’s History

jQuery Mobile was conceived and announced in 2010, three years after the launch of jQuery.  The project was exciting and ambitious. At announcement, jQuery Mobile promised compatibility across multiple platforms, browsers, and versions. Several mobile browser vendors, including Palm and Mozilla, signed on to sponsor the project: 

“The jQuery community has focused on making the Web as productive and fun as possible. When we heard the mission behind jQuery Mobile, we wanted to help. With webOS we have shown that the Web platform is fantastic for developers, so we are excited to help make jQuery Mobile as good as it can be.” -Dion Almaer – Palm

At the time, the mobile web was desperately in need of a framework capable of working across all browsers, allowing developers to build truly mobile web applications. jQuery had already changed the way developers were building on the web, making it easier (and faster) to create secure, compliant applications. 

With jQuery Mobile, the project’s goals were to bring the ease-of-use of jQuery to HTML-capable mobile device browsers and to make it easier for developers to build progressively enhanced web applications. Led by Todd Parker of Filament Group, a development studio known for their work on cross platform and accessibility-first applications, jQuery Mobile launched its alpha release in October 2010. 

Alpha features included several components, layouts and theming tools that simplified the process of building a mobile web application. Progressive enhancement and graceful degradation, which were hot (and tricky) topics in web development at the time, featured heavily: jQuery Mobile promised developers and users the best possible experience their platform could handle. Accessibility was another key feature, with Mobile promising a user experience that could be navigated by touch, keyboard, or screen reader via ARIA compatible components. Additional features such as simplicity, file size, and the ability to deploy jQuery Mobile applications through an app store drove further excitement. 

Over the next year, the jQuery Mobile team continued to add compatible platforms and browsers, new components and themes, and eventually a themeroller tool that allowed developers to configure and download themes without writing any CSS. 

The community response was overwhelming – by the time 1.0 was released in November 2011, jQuery Mobile had gathered over 125 contributors, dozens of articles, tutorials and demos, 8 published books, and a gallery of sites, plugins and extensions to welcome and introduce new developers to the project. 

jQuery Mobile continued to make monthly releases throughout 2012 and 2013, regularly adding and improving components, resolving compatibility issues with mobile browsers, and making performance improvements to speed up page rendering times. The development team also continued to prioritize and highlight the importance of responsive web design and accessibility principles with each new release. 

As the number of components and widgets swelled – both those that were officially supported or widely adopted in the community, performance and compatibility issues with mobile platforms, browsers, and jQuery core were also exacerbated. Though the project did have some automated tests, there were still a number of items that needed to be tested manually, which slowed down the development process. 

In mid 2013, Jasper de Groot became the project lead and announced tighter development collaboration between jQuery UI and jQuery Mobile teams, sharing goals, roadmaps and code in order to ease the workload for both groups. The team continued to provide maintenance releases and support, but progress continued to slow under the burden of testing and supporting such a large community. 

Alex Schmitz took over the lead in July 2014, but by that time the size of the project, combined with the pace and availability of new mobile browser features, made finding a viable path forward for the project increasingly difficult. 

The latest stable version was released October 2014. Alex and team made a big push to update jQuery Mobile again in 2017 with the release of an alpha version of 1.5; this version would see compatibility with jQuery 3.0 and npm support among other things.

jQuery Mobile became an OpenJS Foundation Emeritus project in 2018, signifying that the goals of the project had been achieved.

jQuery modernization initiative

The depreciation of jQuery mobile follows the careful transition of another project under the jQuery project umbrella, jQuery UI.

jQuery Core is still actively maintained and widely implemented. As part of its modernization initiative, the team also has been making a series of updates this year to its infrastructure, including migrating and improving its CDN.

Celebrating jQuery Mobile Maintainers and Contributors

The contributions to jQuery Mobile opened up opportunities for people and organizations around the world, and we are thankful for all the contributions over the years. We would like to give an extra shout out of gratitude to the past maintainers of jQuery Mobile: Alexander Schmitz, Jasper de Groot, and Todd Parker.

As most of you are likely aware by now, a potentially dangerous security vulnerability was highlighted recently in the use of npm modules in your projects. In general, the jQuery Foundation still believes this is a safe and very powerful practice and in no way are we saying you should no longer use npm for package management in your JavaScript projects. What we would like to advocate is caution for our community of jQuery plugin developers and users of the many projects in the foundation who distribute packages on npm when installing a package and its dependencies.

A Quick Recap

Rather than rewrite the story, go ahead and check out the full recap and summary from npm on their blog.

The Concern

What happened next is the reason we are writing this post. Azer Koçulu published a number of packages on npm, one of which was the left-pad package which is a simple bit of code that is depended upon by many other packages. After the package was unpublished, many popular projects began having build failures due to the missing package. This is concerning in itself that anyone could unpublish a dependency you have, or a dependency of a dependency of a dependency and cause you or your team real headaches. Shortly after left-pad was unpublished, the npm team decided to un-unpublish it with a new owner to fix the many breaking builds around the internet. What is more concerning though, is the fact that once a package is unpublished, anyone can grab those package names you depend on somewhere in your dependency tree and push new, potentially malicious code into your project. In general, this wouldn’t be too bad because your package likely relies on a version that was unpublished and the new published version would not be pulled in. However, many people when installing dependencies use the commands npm i --save <package-name> or npm i --save-dev <package-name> which by default installs the latest version published at the time preceded by a ^ like ^1.0.0 which tells npm to install any updated version through minor releases the next time dependencies are updated. This means that if you reinstall or update your project and someone has pushed malicious code into a patch (1.0.1) or minor (1.1.0) release from our example, it will automatically be installed in your project.

Recommendations

Our primary recommendation is to be careful. Know what you are installing and know what your dependencies and their dependencies down the tree are installing. You should definitely go through your projects now and see if any of the modules you depend on have been unpublished as well as if any of them are on this list and have recently published new versions that you may want to avoid until you verify it is safe. Though we haven’t spoken with them directly, we are sure the folks at npm, inc. are working hard on a way to address these concerns but until then, be vigilant and keep your projects and plugins safe. We have believed for a while and continue to believe that JavaScript has been and will continue to be one of the strongest options for developing everything from your personal blog to enterprise class applications. With any technology, we will have hiccups along the way but as long as we learn from them and retain that knowledge as we continue on, JavaScript will prevail.

We’re excited to announce that the Pointer Events specification has become a W3C Recommendation! As we’ve said before, we love Pointer Events because they support all of the common input devices today – mouse, pen/stylus, and fingers – but they’re also designed in such a way that future devices can easily be added, and existing code will automatically support the new device. While reaching Recommendation status is a monumental moment, there’s still much work to do.

Pointer Events aren’t a viable solution until they’re usable in all of the browsers that developers are supporting. While that day may seem far away, the jQuery Foundation is dedicated to getting usable Pointer Events in every developer’s hands as soon as possible. We’re working on PEP, our Pointer Events polyfill that Google transferred from the Polymer project to the jQuery Foundation. PEP will be integrated into projects such as jQuery UI, jQuery Mobile, and Dojo. We’re hoping to get out our first release in the next few weeks. If you’re interested in helping out, let us know.

Microsoft is already shipping a full implementation of Pointer Events in IE11 and they had a mostly complete, prefixed implementation in IE10. Mozilla also has a full implementation for Firefox on Windows Metro, though it’s not currently enabled. Both implementation are passing 100% of the W3C Pointer Events test suite. You can follow Mozilla’s progress for all of their supported platforms on https://wiki.mozilla.org/Gecko/Touch.

Of course, the world ain’t all sunshine and rainbows. There’s still no sign that Apple will ever implement Pointer Events. Because of this, Google has decided not to ship Pointer Events in Blink, but rather to try to extend Touch Events to have the power of Pointer Events. The work to extend Touch Events is happening in the Touch Events Community Group to ensure interoperability and standardization. However, there is reasonable concern that adding several extensions to Touch Events will just result in an even more fragmented landscape, eventually worsening the situation rather than improving it. It’s not clear that Apple would implement all of these features anyway, and adding support for hover would require awkward APIs due to the logic that already exists in Touch Events. Even if the power of Pointer Events were added to Touch Events, the awkward event interface isn’t nearly as nice or easy to transition to from Mouse Events.

Despite Google’s current position, they’re willing to continually re-evaluate if shipping Pointer Events will help move the web forward. We’re hopeful that Google will reverse their decision in the future and Apple will eventually be compelled to implement Pointer Events once Safari is the only major browser without support. The Chromium issue for implementing Pointer Events is already in the the 99th percentile of all issues (open and closed) based on number of stars.

As a community, we can shape the future of the web right now. We need to stop letting Apple stifle the work of browser vendors and standards bodies. Too many times, we’ve seen browser vendors with the best intentions fall victim to Apple’s reluctance to work with standards bodies and WebKit’s dominance on mobile devices. We cannot let this continue to happen. The jQuery Foundation is dedicated to driving standards, like Pointer Events, to improve the developer experience and in turn, make the web a better, more accessible place for everyone. Together, we can push the web forward and let standards and better APIs win. We can choose Pointer Events over Touch Events. And we can do it right now, with PEP.

jQuery UK will take place on March 6, 2015 in Oxford, UK. This event is organised by White October Events with support from the jQuery Foundation.

jQuery UK is the UK’s largest front-end developer conference. Now in its fourth year, two packed tracks will feature the biggest names in front-end, including Bootstrap creator Mark Otto, Standardista Estelle Weyl, Google Engineer Addy Osmani and Jenn Schiffer of Bocoup.

Practical sessions will cover topics including architecting client-side code for resilience, making your code more readable and expressive, and designing for displays that don’t exist yet.

There are four hands-on workshops taking place the day before the conference. Choose from:

• Practical & powerful HTML, CSS, and JavaScript
• Advanced jQuery Techniques
• AngularJS Foundations
• Web Developers Workflow

Space for these workshops is strictly limited, so book early to secure your spot!

Tickets are on sale now at £190 + VAT.

To book tickets or sign up for updates, visit jqueryuk.com. You can also track jQuery UK on lanyrd.com and follow @jquk for updates.

During the last two weeks of September, we found our way into the headlines due to a series of attacks on our web servers. Today, we wanted to give everyone a brief update on the status of our websites and a recap of what happened over the last two weeks.

jQuery Under Siege

Early on the morning of September 18th we were hit with a DDoS and went offline. We were down for a couple of hours. The sites were brought back up later that day on September 18th and all seemed well.

Later, during the afternoon of September 18th, we were contacted by a security company named RiskIQ reporting that their crawler had reported malware being served by our content sites. There were never any reports that the jQuery libraries nor the CDN were ever compromised. Immediately upon receiving that report, we completely destroyed and reimaged all of those machines, revoked and reissued all associated SSL certificates, and confirmed that there was no suspicious content being served at that point. Since then, our own team and security folks from Mozilla and MaxCDN have worked to analyze logs and attempt to confirm the impact of this attack.

On September 23rd, RiskIQ went public with their report which picked up steam throughout the day on various media outlets and Twitter. The next morning, September 24th, as DDoS attacks on our properties continued to increase both in frequency and magnitude, CVE-2014-6271, otherwise known as the ShellShock vulnerability, was issued. As we continued to respond to the media discussion and communicate to the community what had happened on September 18th, we were victimized again in a series of much more public attacks involving the repeated defacing of jquery.com.

Investigations into our systems have yet to find the initial attack vector. However, we did take some steps to make ourselves more secure. For instance, some of our WordPress installs were out of date, all of our servers were vulnerable to the recent shell vulnerabilities, NGINX was slightly out of date as well as maybe a few other patches etc. that needed to be made. The infrastructure team dove in and began making those changes and started building new, fully patched and secured servers to host our sites. It appears these changes were effective as the defacing stopped and we have not seen any evidence of intrusion since.

Later on September 24th, a massive and unrelenting DDoS attack began. It seemed as though it would come in waves, but did not stop until late on September 28th. Most of the time on September 26th and 27th was spent trying to implement various products and solutions in order to keep the servers alive. We fought day and night to try to keep the sites up. We have to commend Corey Frang, Adam Ulvi, the rest of the infrastructure team, and others; they worked through the nights and in alternating shifts to try to keep us on the internet. Without their efforts, we would not have had the short amounts of uptime we did. One significantly important step that we took was to reach out to CloudFlare, who generously and rapidly gave us access to their Enterprise service which has helped tremendously in mitigating these attacks.

Moving Forward

jQuery and the jQuery Foundation are important to the web ecosystem, as is evident from the amount of press and the number of concerned individuals and organizations that have reached out to ask questions about this attack. The jQuery Foundation works on a daily basis to maintain and improve our projects and the infrastructure around those projects. The goal of this work is to continue to make web developers’ jobs easier and make sure they have a voice in the world of standards and browsers. However, these objectives take a large quantity of resources. Whether those resources are provided by access to expertise of a company’s employees or services, or through financial support, we would be unable to continue this important work without the support of the open source community and our supporting members.

We have been asked several times throughout this ordeal about why we didn’t have XYZ service in place or why we didn’t have our security team keeping a closer eye on these types of risks. The simple answer is that our budgets are tight and resources are limited. Our infrastructure team, and most of our teams for that matter, are made up of volunteers who give their time for free to make sure things keep running. The Heartbleed and ShellShock vulnerabilities are recent examples of how badly things can go when open source projects are taken for granted and just assumed to be OK. Eventually something is going to fall through the cracks and those cracks become larger and more frequent when people are doing what they can in their spare time.

So how can you help? As an individual, get involved in one of our projects. We can always use help writing code, designing, maintaining servers, working on events and the list goes on. Take a look at contribute.jquery.org or come say hi on IRC in one of our many channels listed on irc.jquery.org. As an organization, we would love to hear about any service you may be willing to donate, any developers or other skilled professionals that you could spare for a few hours a week or if you can help financially. Send us a message at membership@jquery.org and let us know how you can help.

We haven’t wanted to say too much about these attacks as they have been happening because we remain a juicy target in the eyes of hackers who are continuing to attempt to infiltrate our servers even as of this writing. In sharing all of this information with the community now, we’ve tried to balance the need to explain what’s been happening with the potential backlash that could happen as a result of coming out publicly and saying that we believe we have the situation under control.

That said, we do at this point believe that we have the situation under control. For this, a huge thanks is due to the entire jQuery infrastructure team, who rolled up their sleeves and worked tirelessly on these issues to get us back to a good place. We will continue to be vigilant in ensuring the reliability and safety of all of our resources for our community of users.

Today at 11:15AM EDT, the jQuery Infrastructure team received widespread reports and confirmed a compromise of jquery.com. This attack was aimed at defacing our sites, and did not inject malware like the attack that was reported on September 18th by RiskIQ. We believe that these are separate incidents that may have used the same attack vector.

We took the site down as soon as we realized there was a compromise and cleaned the infected files. We are taking steps to re-secure our servers, upgrade dependencies, and address vulnerabilities.

At no point today have there been reports of malware being distributed from any of our sites, nor has the code of any jQuery libraries on our website or CDN been affected or modified today or during last week’s reported attack. Some of this confusion stems from last week’s attackers having set up a domain name intended to dupe users into thinking it was the official jQuery CDN. Please note that the official domain for jQuery files hosted from our official CDN is code.jquery.com.

There has also been concern that the user accounts of developers and administrators who use jquery.com and the rest of our WordPress sites have somehow been compromised by this attack. However, the only people who have a user account for the WordPress sites affected by these attacks are members of the jQuery team; we do not have any public user registration for any sort of account on any of the affected sites.

We are continuing to actively work on and monitor this situation and will update you as we learn more.

Updates

We have moved http://jquery.com to a new server only running code we trust and are continuing to monitor the situation closely. – September 24, 2014 at 5:07 PM EDT via Twitter

Lastest update on the compromise: Update on jQuery.com Compromises

Earlier today, RiskIQ published a blog post stating that the jQuery.com web servers were compromised and serving the RIG exploit kit for a short period of time on the afternoon of September 18th. Our internal investigation into our servers and logs have not yet found the RIG exploit kit or evidence that there was in fact a compromise.

RiskIQ was able to make contact with the jQuery Infrastructure team on September 18th, at which point with members of the RiskIQ team tried to find evidence of compromise. So far the investigation has been unable to reproduce or confirm that our servers were compromised. We have not been notified by any other security firm or users of jquery.com confirming a compromise. Normally, when we have issues with jQuery infrastructure, we hear reports within minutes on Twitter, via IRC, etc.

At no time have the hosted jQuery libraries been compromised.

Currently the only potential system compromised is the web software or server that runs jquery.com. We have asked RiskIQ to help us look through our server logs and systems to help identify when and how a compromise happened. Please check this blog post for updates on the situation.

Even though we don’t have immediate evidence of compromise, we have taken the proper precautions to ensure our servers are secure and clean. If you happened to visit any of the our sites on September 18th and are afraid of your system being compromised you can follow the advice RiskIQ recommends:

• Immediately re-image system
• Reset passwords for user accounts that have been used on the system
• See if any suspicious activity has originated from the offending system

With just over a month until we set forth for the Windy City for the first jQuery Conference in Chicago, the moment’s opportune to bring you up to speed on what we’ve got in store for you this September!

Whatchu Talkin’ Bout?

Our speakers and talks are the highlight of any jQuery conference; our lineup in Chicago is no exception. We aim to cover a broad selection of subjects from across the realm of web development, from our jQuery Foundation projects like jQuery, jQuery UI, and jQuery Mobile (so we’ll be having talks from project leads Dave Methvin, Scott González, and Alex Schmitz) to the new frontiers where JavaScript now treads (so we’ve got Lisa Deluca talking about using Arduino and Cordova together, and Micah Ransdell talking about Netflix’s adoption of Node.js). We know you want to know more about the future of the open web platform, and that’s why we’re happy to have folks like John K. Paul to go over coming changes to the language in ECMAScript 6, and TJ VanToll and Kevin Hakanson to discuss new browser APIs for form validation and cryptography.

A lot of you come to conferences to learn practical things you can take home with you, and that’s why we’re excited about sessions from (among others) Brian Arnold and Cory Gackenheimer on debugging techniques and Phil Dutson on the process of building a jQuery plugin.  We know, however, that there’s a lot more to releasing code than, well, writing code, and we’re happy to have Kassandra Perch, Alex Sexton, and Kelly Andrews joining us to talk about how to choose and use tools to ship and support the projects we work on. And we know some of you travel to conferences for the fun and games, and we’re thrilled to have Sara Gorecki and Bodil Stokke on hand to talk about building games with web technology.

This is just a handful of the speakers and subjects that’ll be on our Chicago stage(s), and we invite you to take a few minutes to check out our entire program to see what else is on the docket!

Can You Hack It At #jqcon?

Of course you can! In Chicago, however, we’re partnering with MaxCDN, DigitalOcean, and MediaTemple to officially encourage you to do so! We’ve got a wealth of data about how folks use the jQuery CDN at code.jquery.com, and it’s up to you to help us understand it. The hackathon starts the night before the conference on September 11th, and you’re free to use any medium you see fit to play with the data, whether it’s a web application or a robot. Our sponsors have stepped up to reward three participants with bountiful rewards, so we hope you join us to team up, explore, and build!

Coming Home to Roost

We’re partnering with Bocoup for the second time this year to extend our trip to Chicago with Roost, a two-day intensive class on building modern web applications taught by Ashley Williams, Ben Alman, Irene Ros, and Mike Pennisi. Roost is targeted at developers who already know JavaScript, jQuery, HTML, and CSS, and are looking to understand how to develop a better workflow for building, testing, and maintaining their applications and incorporate technologies like Backbone, RequireJS, Stylus, and more. You can check out the full training curriculum and schedule to find out exactly what’s planned.

Accommodations

Both jQuery Conference and Roost are taking place at the Sheraton Chicago in the heart of the city, so the hotel’s a convenient place to stay for the purposes of both your edification and your vacation. We’re only able to offer a discounted rate of $269 per night until August 15th, so make sure to make your reservation in our room block as soon as you can! Staying in our room block is a really helpful way you can help the jQuery Foundation fulfill some of the large financial commitment we’ve made by setting up shop in Chicago.

Brought To You By

Our sponsors and foundation members make a huge difference in our ability to host an awesome jQuery Conference for the community, and we’re happy to take a moment to thank them right here! So here’s a big THANKS to Diamond sponsors WordPress and IBM, Platinum sponsor MediaTemple, Gold sponsors MaxCDN, Bocoup, BrowserStack, Mandrill & DigitalOcean, and Silver sponsors Pebble & Accenture. (We’re still welcoming sponsors – if you’d like to have your company be a part of #jqcon, please reach out!)

Student Discount

We’re glad to be able to offer a discount to current students interested in attending jQuery Conference or Roost. Please get in touch with us for more information on how you can save $150 on tickets to one event, or $200 on a combination ticket. We know the discount is modest, but this is only the second time we’ve been able to offer a student discount of any kind, and we hope it helps. Please be advised that if you use this discount, you’ll need to show a valid student ID at registration.

Join Us

The summer’s been flying by and we can’t believe we’re only five weeks out, and we hope you’ll consider joining us on our trip (or that you’ve already booked your ticket!). Check out the conference site for more on our program and speakers, lodging, and to buy your tickets. If you have any questions, always feel free to get in touch with us on Twitter or via e-mail.

The other day, we posted about our new content workflow, but we didn’t get into how all that content is actually served. Believe it or not, jQuery doesn’t just run on jQuery.

The servers

The servers themselves are hosted at Media Temple. We have been using their VPS services for many years to host all the things we need to host, of which there are a surprising number. We use over a dozen different servers (of various sizes) hosting everything in the jQuery network including many different web sites, applications and services vital to the community and development team. The reliability of the Media Temple VPS services and network for our infrastructure has been fantastic.

The setup

We couldn’t manage all of the servers without Puppet. Puppet is a configuration management tool that makes it really easy to express server configuration in a simple scripting language. Tasks like adding a domain to the Nginx configuration can be annoying, and hard to track changes using conventional methods. Using Puppet lets us store all the server configuration needed in a git repository, and deploy new machines very easily.

Another product that really shines in our setup is Nginx. Nginx is an open source web server focused on delivering the best performance possible. On our busiest Media Temple Dedicated Virtual server around peak times, Nginx handles about 300 HTTP requests per second, of which about 30 are serving pages from WordPress via php-fpm. Nginx’s built in fastcgi_cache handles a lot of that load, and more like 2 or 3 requests per second actually make it to PHP.

Thanks for the support!

Keeping a network of servers running to support a community as large as jQuery’s is a big job. To help ensure everything runs smoothly, we rely on jQuery Infrastructure team members Adam Ulvi and Ryan Neufeld, and for server and network-related issues we count on prompt and helpful support from the Media Temple team.

To celebrate their 7 years of serving the jQuery community, Media Temple is extending a special offer on their VPS and Grid Hosting. For the next 5 days, get 50% off an annual purchase of a Grid or VPS (up to level 3) service with the code LovejQuery50.

Speaking of support, if you need any support with jQuery, or the related web sites and services, check out one of our IRC channels on freenode.

Maintaining an open source project as big as jQuery requires the use of various software and services. Two of the products we rely on and enjoy the most are GitHub and WordPress.

We’ve been using and loving Git and GitHub for years now. The community collaboration has been phenomenal. We’ve seen a massive uptick in community-provided bug fixes, refactors, new features, etc. Even within the team, the services provided by GitHub have provided a huge productivity boost. Forks and pull requests provide a great mechanism for sharing code and peer code reviews. The interface renders almost every file exactly how we want it to, especially Markdown. The API and service hooks provide a great way to automate various tasks.

Even longer than we’ve been using GitHub, we’ve been using WordPress to manage our various web sites. We have a surprisingly large number of them. Between project sites, API documentation, tutorials, contribution guides, events, and organization sites, the number of web sites we maintain rivals the number of code projects we maintain. WordPress provides tools which make managing this many sites with a common brand almost as simple as maintaining just one site with shared users, theme inheritance, and a great plugin architecture, providing even more hooks than GitHub.

The missing pieces

Unfortunately, our WordPress experience lacked all the collaboration tools and workflow we love. Only a few people had access to edit content, and collaboration without pull requests is painful. Managing content on api.jquery.com was an even bigger hassle because of our XML based workflow, which the WordPress editor clearly wasn’t designed for.

While GitHub has tons of tools that we love, and they even have GitHub Pages, it lacked the infrastructure we need for managing our site content. GitHub Pages have no built-in features and can’t have any server-side processing. Features like search and commenting either need to be added per site via client-side JavaScript or can’t be implemented at all.

Bringing it all together

In order to resolve these issues, we decided to find a way to bring these two products together and get the best of both worlds. It started off pretty bumpy, but we managed to do just that! Things started to really pick up when we got the support of WordPress’ Lead Developer Andrew Nacin. Nacin played a key role in getting our new infrastructure set up and ensuring we were using WordPress as efficiently as possible. With his help, and the help of a few new projects – such as node-wordpress, grunt-wordpress, and grunt-jquery-content – we were able to build exactly what we wanted.

We now manage our WordPress theme in jquery-wp-content, and the content for all of our sites are stored and managed in individual repositories on GitHub. Storing the content of each site on GitHub gives us all the benefits of tracking tasks in issues, discussions on pull requests, visual diffs for changes, etc. The content of each page is generated by grunt-jquery-content from HTML, XML or Markdown source depending on the repository. This content is then synced to WordPress using grunt-wordpress. Just like our code, all of our site content is open source and released under the terms of the MIT license, with the exception of our branding which is not licensed for use by others.

We’re now powering a dozen and a half sites with this new process, averaging 20 contributors per site. Our most popular sites for community contribution are learn.jquery.com which is nearing triple digits and api.jquery.com which currently has 50 contributors. We’re averaging 40 pull requests per site as well, showing just how beneficial this new workflow has been for the team and the community. If you’d like to join in on this community effort, you can read more about our process and how to get involved on our contribution site and help make jQuery better for everyone.