By far the most common request in the WordCamp.org tools survey results was for the ability to write custom PHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/preface.php. and JavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/.. This is definitely understandable, because being limited to only modifying CSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. does significantly restrict what you can do with your site.
Why not allow custom PHP and JavaScript?
The reason that this restriction exists is because there would be very serious security and maintenance implications if we were to open things up.
Security is very hard, even for experienced developers. Everybody makes a mistake at least occasionally, and many developers don’t realize how often they do.
There’s no doubt that allowing unreviewed PHP or JavaScript would introduce critical vulnerabilities, not just to WordCamp.org, but to the rest of the WordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ infrastructure as well, and even to regular WordPress sites interacting with the infrastructure.
WordCamp.org is connected to the rest of WordPress.org in several key ways, and the right kind of vulnerability (or combination of vulnerabilities) could allow an attacker to do some pretty scary things, like silently stealing password hashes or authorization cookies. If they targeted someone with commit access to Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress., WordPress.org, or a popular plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party, then the results would be severe.
Of course, we have access controls, monitoring, and other systems in place to minimize the chance of an attack and mitigate its effectiveness, but the essential threat is there and can’t be downplayed.
Why not just review custom code before it’s committed?
We just don’t have the resources to review that much code. There are only two developers who handle the vast majority of the work on WordCamp.org, and both of us also have responsibilities on other projects. So, we have roughly the equivalent of one full time developer. There were 80 WordCamps in 2014, and that number grows every year.
Conducting a thorough security audit and code review takes a significant amount of time, and simply isn’t possible with the resources we have.
Imagine giving hundreds of developers access to one of your high profile sites, or committing to review hundreds of themes and plugins every year while still trying to build new features and iterate on existing ones.
Other potential solutions
- Assemble a team of volunteers to review code – Because of the security concerns, any volunteers would need to be very experienced and a trusted member of the community, and because of the volume of sites, we would need to have a lot of them. I don’t think we’d be able to keep up with the demand, and we’d also be taking those people away from contributing to other projects. It’d be much more efficient and make a bigger impact if those people collaborated on projects that could be shared between all camps instead.
- Let everyone host their own site – This is how things were in the early days, but we moved to a centralized platform because it was common for domain names to expire, or for the current year’s team to be unable to post an announcement to the previous year’s site, or for sites to be unmaintained and get hacked, etc. It would also mean that organizers would have to spend extra time setting up hosting, and, because of security concerns, anything that requires connecting to WordCamp Central Website for all WordCamp activities globally. https://central.wordcamp.org includes a list of upcoming and past camp with links to each. or the WordPress.org infrastructure would become much more complicated (e.g., centralized payment requests and ticket revenue collections, single sign-on, integration with Profiles.WordPress.org, etc).
- Create each site inside an isolated, virtual container – That would require a lot of work from the Systems team, who are also very limited on resources, and it would have the same downsides as above, where anything that connects to Central or WordPress.org would become much more complicated.
- Only let experienced developers write custom code – The security concerns would force us to set the bar very high, and evaluating a developer’s qualifications is itself a time-consuming process, so this would only impact a small number of camps. It could also make it appear like certain camps were getting special treatment, and lead to hurt feelings when someone who feels like they’re experienced enough isn’t accepted.
What makes the most impact?
WordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. sites are tools that help organizers communicate with attendees. It’s great to have a design the community can take pride in, and working on the site can definitely be a community-building experience, but volunteer hours are limited. It’s best to focus on things that will inspire and connect attendees at the event, rather than making the website perfect.
At the end of the day, attendees will be helped the most by the sessions, workshops, networking, and contributing that goes on at the event.
The goal of WordCamp.org is to give organizing teams something that works out of the box and facilitates all of the basic conference services that most WordCamps need, so that you can spend your limited time on the event, rather than the website for the event.
Solutions that benefit everyone
Allowing organizers to write custom PHP/JavaScript isn’t the real goal, it’s just a means to an end; and I think there are better ways to get there.
For the most part, all of our camps have very similar needs, so rather than each one re-inventing the wheel on their own, it’s much more efficient if we collaborate on solutions that work for everybody.
The survey results helped us identify the worst pain points with the current tools, and we’re planning solutions to improve the CSS editing experience, to give more theme/template options to choose from, and to be able to easily clone another camp’s site instead of having to start from scratch. The feedback on all of those was that they’d have a huge impact on everyone’s ability to create the sites they want.
I think that focusing our time and energy there is going to be much better for everyone in the long term. If you’d like to help move those projects forward, please check out the survey recap for next steps.
And if there’s a project that would benefit everybody, but it’s not on that list, you can always work with the Community Team to build a consensus for it, and organize a group of developers from local communities to contribute it. You don’t have to be a developer yourself; many projects need people to organize everything, create designs, write documentation, perform user testing, etc.
#improving-wordcamp-org, #maintenance, #official-websites, #security, #wordcamp-org
