Latest PECL Releases:
cgi-fcgi SAPI #835
The post Interview with Derick Alangi appeared first on Voices of the ElePHPant.
The post Interview with Derick Alangi appeared first on Voices of the ElePHPant.
Another monthly update where I explain what happened with Xdebug development in this past month. These will be published on the first Tuesday after the 5th of each month. Patreon supporters will get it earlier, on the first of each month. You can become a patron to support my work on Xdebug. If you are leading a team or company, then it is also possible to support Xdebug through a subscription.
In March, I worked on Xdebug for about 60 hours, on the following things:
The 2.9.5 release addresses a few bugs. One of them was a follow on from the issue where Xdebug would crash when another extension would run code in PHP's Request Init stage, but only on a second or later request in the same PHP process. As this is not something that's easy to catch with PHP's testing framework that Xdebug uses, this issue slipped through the cracks.
The release fixes another bug, where throwing an exception from within a destructor would crash Xdebug. The fix for this was merely making sure that PHP's internal state is still available:
- if (!(ZEND_CALL_INFO(EG(current_execute_data)) & ZEND_CALL_HAS_SYMBOL_TABLE)) {
+ if (EG(current_execute_data) && !(ZEND_CALL_INFO(EG(current_execute_data)) & ZEND_CALL_HAS_SYMBOL_TABLE)) {
Beyond these two crashes, the release also addressed an issue where Xdebug did not always correct catch where executable code could exist for code coverage analyses. Over the last decade, PHP has been getting more and more optimised, with more internal engine instructions. Unfortunately that sometimes means that these are not hooked into by Xdebug, to see whether there could be a line of code that would make use of these opcodes. As this is often very dependent on how developers lay out their code, these issues are often found by them. Luckily, these issues are trivially fixed, as long as I have access to just the file containing that code. I then analyse it with vld to see which opcode (PHP engine instruction) I have missed.
Most of my time was spend on getting Xdebug Cloud to a state where I can invite select developers to alpha test it. This includes allowing for Xdebug to connect to Xdebug Cloud. There is currently a branch available, but it still lacks the addition of SSL encryption, which is a requirement for allowing safe transport of debug information.
The communications between an IDE and Xdebug through Xdebug Cloud is working, with a few things related to detecting disconnections more reliably still outstanding.
As Xdebug Cloud needs integration in debugging clients (such as PhpStorm, and other IDEs), I have been extending the dbgpProxy tool to act as intermediate link between existing IDEs and Xdebug Cloud without IDEs having to change anything. This work is still ongoing, and is not documented yet, but I hope to finish that in the next week. Once that and SSL support in the Xdebug to Xdebug Cloud communication has been finalized, I will reach out to subscribers of the Xdebug Cloud newsletter to see if anybody is interested in trying it out.
In April, no new supporters signed up.
If you, or your company, would also like to support Xdebug, head over to the support page!
Besides business support, I also maintain a Patreon page and a profile on GitHub sponsors.
The PHP Internals News continues its second season. Episodes in the last month included a discussion on PHP 8's JIT engine and increasing complexity,
Truncated by Planet PHP, read more at the original (another 720 bytes)
April continued to be a challenging time for the WordPress community, with many under stay-at-home recommendations. However, it was also an exciting month in which we created new ways to connect with and inspire each other! This month, amazing contributors moved more WordCamps online and shipped new releases for WordPress and Gutenberg. For the latest, read on.
On April 24th, WordPress 5.4.1 Release Candidate 1 (RC1) was released for testing, quickly followed by the official release of WordPress 5.4.1 on April 29th. This security release features 17 bug fixes and seven security fixes, so we recommend updating your sites immediately. To download WordPress 5.4.1, visit your Dashboard, click on Updates, then Update Now, or download the latest version directly from WordPress.org. For more information, visit this post, review the full list of changes on Trac, or check out the version 5.4.1 HelpHub documentation page.
Want to get involved in building WordPress Core? Follow the Core team blog, and join the #core channel in the Making WordPress Slack group.
It was another exciting month for Gutenberg, with the release of 7.9 and 8.0! Version 7.9 brought new block design tools, three new patterns, and improved block markup. Gutenberg 8.0 continued to refine the new block patterns feature, with additional options for inline formatting, and extending the functionality of the Code Editor. In addition to these new features, both releases included new enhancements and APIs, along with a number of bug fixes, performance improvements, some experiments, and more! You can read all the details about the latest Gutenberg releases in the announcement posts for 7.9 and 8.0.
Want to get involved in building Gutenberg? Follow the Core team blog, contribute to Gutenberg on GitHub, and join the #core-editor channel in the Making WordPress Slack group.
BuddyPress 6.0.0-beta2 was released for testing in mid-April, leading to the BuddyPress 6.0.0 Release Candidate, announced on April 29. This is an important step before the final release of BuddyPress 6.0.0, which is slated for Thursday, May 14. Changes and new features in this release include moving the profile photo and user cover image under the BP Members component, and a new BP Rest API. Additionally, this release will introduce the first round of BuddyPress Blocks! Last, but not least, BuddyPress 6.0.0 will require at least PHP 5.6 and WordPress 4.8.
Want to get involved? Test the 6.0.0-RC here! You can also help by translating BuddyPress into another language, or let the team know of any issues you find, either in the support forums and/or in their development tracker.
WordCamp US will take place online due to the COVID-19 pandemic. The event still runs from October 27-29, 2020, and will be free to anyone who wishes to attend. The team plans to offer what WCUS has historically brought to the community in person: sessions and workshops, Contributor Day, a hallway track, and of course, State of the Word.
Interested in speaking at WCUS? The Call for Speakers is still open! You can apply to speak on the speaker application site until May 31, 2020 at 11:59 pm CDT (UTC-5).
Additionally, the Call for Cities is also open. If your community is interested in hosting WordCamp US in 2021 & 2022, please fill out this application.
For the latest information about WordCamp US, sign up for updates on the website, or follow Facebook, Twitter, or Instagram.
Last month, WordCamp Europe decided to postpone its Porto event to 2021. This April, the WCEU organizing team announced that the 2020 WordCamp will be online! WordCamp Europe 2020 Online will take place from June 4-6, 2020, and tickets will be free. There will be a virtual Contributor Day on June 4, and then two half days of live-streamed talks and workshops. To participate, get your free ticket here.
To get the latest news for WordCamp Europe 2020 Online, follow on Facebook, Twitter, LinkedIn, or on Instagram.
Have a story that we should include in the next “Month in WordPress” post? Please submit it here.
Handing off a new WordPress website to a client offers a great feeling of satisfaction. You provide a pixel-perfect rendering of a brand’s online presence and hope it plays a key role in a company’s success.
But, if your client is responsible for managing content themselves, those pixels may no longer be so perfect after a while. You may find that your carefully-crafted layouts and typography have been rendered a mess by a well-meaning user. Color contrasts designed for maximum accessibility become illegible.
For so long, this has been accepted as the natural order of things. We design pretty and functional things; clients make them slightly less pretty and functional.
It doesn’t have to be this way! With a little creative thinking, technical knowledge and education, we can build WordPress websites that can withstand a bit more punishment – and even avoid such situations in the first place.
One of the best ways to prevent a client from accidentally changing a key setting is to take away their means to do so. That’s what WordPress user roles and capabilities are for.
It’s fairly common to see clients provided with administrator-level accounts for their website. But this enables them to do everything. They can activate themes, remove or install plugins and make any number of other changes. A curious user could do some real damage.
However, it’s usually not necessary for them to have this type of access for everyday tasks. For most content management duties, an Editor account provides enough access and keeps users away from anything dangerous.
For Editors, theme and plugin management are off the table. This can eliminate some of those potential issues. Going to even lower account levels limits users even further by cutting out content that they didn’t create. That could, for example, save a home page from an unintended consequence.
If someone needs a bit more specialized capabilities, a custom user role can be created to accommodate them.
That said, a client should ideally have an administrator account on hand – just in case. But a lower-level account should be used for day-to-day site management.
One common mistake in the design and development process is creating elements that rely too much on good faith. They are destined to cause problems down the road.
For instance, consider a card UI layout that displays the latest blog posts. There are a number of ways to build this type of feature.
We could configure things so that our clients need to write a post description through a custom field. That’s great, but what if they enter too much text? We could risk breaking or severely throwing-off the layout.
Sure, you can explain that the post description field should contain no more than x amount of characters. But that still leaves the possibility of something going wrong. And, even if one person heeds your advice, that doesn’t mean the next person will do the same. It’s just not sustainable.
The better solution is to build in safeguards – or, better yet, automatically generate that post description via a template.
A safeguard could include setting a character limit on the post description field. This allows a client to write their own copy, while preventing too much text. Automatically generating an excerpt, however, will simply take the decision out of a user’s hands.
Either way, it’s important to consider what might go wrong when designing and building features.
Some portions of a WordPress website are difficult (if not impossible) to fully make design decisions for clients. In general, this is because the CMS, theme and plugins offer users a number of different choices.
A page builder plugin or even the Gutenberg block editor make it possible for a user to drastically change a layout. This is one of the down sides of an increasingly visual design process.
Unfortunately, there’s only so much web designers can control here. Some page builders let you turn off features for specific user roles, which could be helpful. There is also the potential to lock down block editor templates, but it’s not always a realistic option.
One neat feature of Gutenberg is the ability to define custom color palettes, which can help users make brand-appropriate choices for blocks. The same goes for gradients and font sizes.
Combine these customizations with disabling the ability to choose beyond the options you’ve defined and users can’t go outside of these parameters. That means no crazy color combinations or tiny font sizes.
Not all WordPress software has these capabilities, however. If you don’t see any obvious settings for a theme or plugin, check out the documentation. Fail that, it might be worth contacting the author to see if there are any undocumented hooks or filters to help you rein in users.
The most important part of keeping your design and functionality in tact is thinking ahead. Plan for how that beautiful design element is going to withstand everything your client might throw at it. Consider the possibility of something breaking and ways to prevent it from happening.
You may not be able to stop a determined client at every turn. But you can build and manage a WordPress website in a way that rebuffs the most egregious issues. That should provide both you and your client with some extra peace of mind.
The post Building Client-Proof WordPress Websites appeared first on Speckyboy Design Magazine.