Charles is a web debugging proxy application for Windows, Mac OS, and Linux. Here’s a quick description from the project’s website:
Charles is an HTTP proxy / HTTP monitor / Reverse Proxy that enables a developer to view all of the HTTP and SSL / HTTPS traffic between their machine and the Internet. This includes requests, responses and the HTTP headers (which contain the cookies and caching information).
And here are some key features:
- SSL Proxying – view SSL requests and responses in plain text
- Bandwidth Throttling to simulate slower Internet connections including latency
- AJAX debugging – view XML and JSON requests and responses as a tree or as text
- AMF – view the contents of Flash Remoting / Flex Remoting messages as a tree
- Repeat requests to test back-end changes
- Edit requests to test different inputs
- Breakpoints to intercept and edit requests or responses
- Validate recorded HTML, CSS and RSS/atom responses using the W3C validator
Pretty much every browser these days comes with developer tools (like Google Chrome, for example).
But these are mostly useful for requests made by the browser itself. Often, like depicted in “PHP and cURL: How WordPress makes HTTP requests” blog post from which I learned about Charles, one needs to examine requests made by the application itself – like WordPress in this particular case.
The developer tools of the browser won’t be very useful, but a proxy application like Charles would. Setting up a proxy will send all requests through it, allowing for easy inspection and debugging.
SitePoint runs through a few options that one can use to synchronize WordPress live and development databases. I’ve linked to some of these options before, but it’s nice to have them all conveniently together. The solutions discussed include WordPress-specific tools:
as well as generic tools, such mysqldump, mysqlpump, rsync, and git.
Overall, it’s a pretty complete list of tools. The one I’d like to add though is WP CLI, which allows a great deal of automation when it comes to WordPress, including things like database imports and exports, post and option management, and more.
I came across this article – “Dependency Management and WordPress: A Proposal“, which provides an excellent overview of some of the recent developments and discussions in the area of composer integration with WordPress, and even more generically, some of the issues around dependency management in an ecosystem as large and complex as that of WordPress.
It’s been a while since I checked what’s going on in this area. A couple of years back, I linked to an article that shows a way to use composer with WordPress, and since then I’ve built something similar for our use at work.
But it’s good to see that the problem is not tossed and forgotten, and that there are some very smart people still trying to work it out.
WP-CFM is a WordPress plugin which helps to manage and deploy WordPress configuration changes between different sites. I haven’t tried it myself yet, but it looks super useful as it allows to separate the configuration options from the content, both of which are stored in the database. The cherry on top here is the support for WP-CLI, command line interface to WordPress, which is frequently employed for automatically deploying WordPress to different servers and environments.
I have a feeling this plugin will be making its way into our project-template-wordpress setup pretty soon.
If Vim is your editor of choice, and WordPress is something you work with on a regular basis, then check out WordPress.vim – a Vim plugin for WordPress development.
Some of the features are:
- Auto-Completion for the WordPress API
- WordPress Hooks Integration
- WP-CLI Integration
- Jump to Definition in WordPress Core
- UltiSnips Snippets
- Syntax Highlighting for WordPress PHP files.
- Markdown Syntax Highlighting for readme.txt
- PHPCS Syntax Checker integrated with WordPress Coding Standards
- Search in Codex
- Integration with WpSeek API.
- Readme.txt Auto Validation.
WordPress Theme Developer Handbook:
The Theme Developer Handbook is a repository for all things WordPress themes. Whether you’re new to WordPress themes, or you’re an experienced theme developer, you should be able to find the answer to many of your theme-related questions right here.
Finally, there is a more organized resources that WordPress Codex!
This bit from the WordPress Dev Chat Summary made me smile today:
Minor releases will continue to follow the philosophy of trying to fix more bugs than we create.
Simple, elegant and effective…
WordPress Tavern states:
WordPress now powers 27.1% of all websites on the internet, up from 25% last year. While it may seem that WordPress is neatly adding 2% of the internet every year, its percentage increase fluctuates from year to year and the climb is getting more arduous with more weight to haul.
Linking to these statistics from W3Techs. Impressive!
Those who think that WordPress is just a blogging system are far from the truth…
WordPress 4.7 is just around the corner (this month). Here is a field guide, detailing what are the changes (and there are plenty!) and what to pay attention to during and after upgrade of your site, as well as what plugin and theme developers should check for the maximum compatibility with the upcoming release.
WordPress 4.7 Field Guide
Holly Molly, that’s a lot of changes!
Over 447 bugs, 165 enhancements, 8 feature requests, and 15 blessed tasks have been marked as fixed in WordPress 4.7.
Pascal Birchler of the WordPress blogs some interesting research he did in the area of handling preferred language and how different systems – ranging from browsers, wikis, and social networks to all kinds of content management systems – approach and solve the problem.
Drupal 8 has a rather powerful user interface text language detection mechanism. There is a per session, per user and per browser option in the detection settings. However, users can only choose one language, so they cannot say (in core at least) that they want German primarily and Spanish if German is not available. But the language selected by the user is part of the larger fallback system, so it may fall back further down to other options.
The Language fallback module allows defining one fallback for a language, while the Language Hierarchy module provides a GUI to change the language fallback system. It allows setting up language hierarchies where translations of a site’s content, settings and interface can fall back to parent language translations, without ever falling back to English. This module might be the most interesting one for our research.
Apart from the research itself, I think this is an interesting example of how complex some seemingly simple features are.