Without User Consent: An Ethical Dilemma for WordPress Plugin Developers

I recently discovered that a popular WordPress plugin had enabled automatic updates without explicitly informing users. How did I find out? I received emails from each site where the plugin was installed informing me that an update had been completed.

But it gets better. Over a holiday break, a colleague asked me to look at a website that wasn’t loading properly. I turned on debugging to find that – you guessed it – this particular plugin was the culprit. The automatic update failed, and some key files were missing. Thankfully, manually uploading a fresh copy of the code fixed the issue.

The incident got me thinking about the ethics behind this move. Not just with a specific plugin author, but all WordPress theme and plugin developers as a whole. So, I reached out to others on the Advanced WordPress Facebook group to get some feedback. Should users have been notified that automatic updates were turned on?

There was some great discussion about the pros and cons of doing this. And Search Engine Journal examined the issue in an article as well. It turns out that a lot of web professionals weren’t thrilled with the idea of enabling this feature without prior notice.

With that, let’s take a closer look at this ethical dilemma faced by WordPress developers – and the development community as a whole. They are a bigger part of the job than you may think.

The Security Conundrum

One can make the case that the plugin authors were at least partially motivated by WordPress security. When a plugin has a security hole, it means websites are exposed until that exploit is patched. Historically, website owners (or their web designers) have been responsible for applying the updates.

Of course, not everyone applies updates regularly. That’s why WordPress 5.5 introduced an auto-update feature. It allows website owners to opt into updates for their themes and plugins. Minor versions of WordPress core have automatically updated for years, and WordPress 5.6 allowed major versions to do the same.

Now, your entire site can be on auto-pilot. This functionality can be a great way to limit exposure to exploits. But the usefulness of this feature isn’t really the question. It’s the implementation.

If plugin or theme authors can simply turn on this feature without informing users, it’s an accident waiting to happen. The scenario I experienced is but a minor example. Imagine if someone used this to push malicious code out to millions of sites that readily applied it. Even if it’s not likely, it’s still possible.

Does that make turning on auto-updates by default worth the risks? Or, does it outweigh the security risks of not doing so?

Make Users Aware of Changes

There are plenty of justifications for turning on auto-updates and letting users discover it on their own (or perhaps never). A common refrain is that most people don’t pay attention and therefore it’s better to protect them. Or maybe a plugin has a dependency that requires lockstep updates.

Maybe that makes sense in some cases. But I’d still argue that the ethical thing to do is to tell users about these types of changes. Or, at least make an honest effort to do so.

The WordPress notification UI is littered with messages about Black Friday sales and new features. Why not use it to communicate something important? Even if it gets lost in the clutter, at least a plugin author can say they tried.

Taking it a step further, clearly announcing such a change in an official blog post, social media or support forum would also be helpful. Any channel of communication that connects developers to users is game.

The Better Option? Let Users Decide

I believe that one of the biggest lessons to come out of this situation is that turning on a potentially-breaking feature without notice is bad for customer relations. And, despite the good intentions of a developer, some people are going to take issue with the practice – quite loudly.

It’s reminiscent of the time Apple included a U2 album in everyone’s iTunes account. What was supposed to be an act of benevolence was met with, well, rage in some cases.

For WordPress plugin and theme authors, the better path may be to encourage automatic updates. Use those same channels to advocate for the feature, rather than forcing users to opt-out. That builds trust as opposed to suspicion.

Will as many people use the feature? Probably not. But the psychology at play here will make you look better in the eyes of the people who use your product. They’ll be more likely to stick with you and make future purchases.

Very few things are certain in life. But you can usually count on users to tell you what they think of your decisions. Therefore, it’s important to listen and learn.

The post Without User Consent: An Ethical Dilemma for WordPress Plugin Developers appeared first on Speckyboy Design Magazine.

Community News: Latest PECL Releases (01.12.2021)

Latest PECL Releases:

• igbinary 3.2.2RC1
  * Update php version check to allow igbinary to be statically built in PHP 8.0+
  • Fix bug in out of memory error handling in __sleep, slightly speed up serializing with __sleep.
  • Continue serializing remaining properties if a missing property name is returned from __sleep.
  • Speed up serializing by optimizing for the case where there is no memory manager override. When there is a memory manager override, only use that for allocating the string to return. (benchmarks/serialize-scalar-int.b.php showed a speedup from 0.22 to 0.18 seconds for repeated serialization of a single scalar, and from 0.186 to 0.180 seconds for benchmarks/serialize-stringarray.b.php for an array of strings)
  • Speed up unserializing arrays in php 7.2-8.0 by adding optimized code for finding the hash bucket of a string/integer key of an array, or creating a placeholder if it does not already exist.
• vld 0.17.1
  - Added support for PHP 8.0.
• swoole 4.6.1
  Enhancement --- + Added --enable-thread-context option (#3970) (@matyhtf) + Strict session_id, check the connection activity (#3993) (@matyhtf) * Optimized CURLOPT_PROXY, support user, pass and scheme (swoole/library#87) (sy-records)

  Fixed

  • Fixed minimal PHP version (#3979) (@remicollet)
  • Fixed pecl install missing enable-swoole-json and enable-swoole-curl options (#3980) (@sy-records)
  • Fixed openssl thread safety issue (swoole/swoole-src@b516d69) (@matyhtf)
  • Fixed enableSSL coredump (#3990) (@huanghantao)

  Kernel

  • Optimized ipc writev, avoid coredump how event data is null (#3994) (@matyhtf)
• swoole 4.5.11
  Enhancement --- * Optimize table (#3959) (@matyhtf) * Enhancement CURLOPT_PROXY (swoole/library#87) (@sy-records)

  Fixed

  • Clear all columns when incr and decr (#3956) (@matyhtf)
  • Fixed compile error (49fea171) (@matyhtf)
  • Fixed fread bugs (#3972) (@matyhtf)
  • Fixed openssl thread safety issue (7ee2c1a0) (@matyhtf)
  • Fixed Invalid argument supplied for foreach (swoole/library#80) (@sy-records)
  • Fixed trigger_error param error (swoole/library#86) (@sy-records)
• PKCS11 0.1.1
  - Added a lot of new test cases - Refactored some Object related functions
• maxminddb 1.9.0
  * The `maxminddb` extension is now buildable on Windows. Pull request by Jan Ehrhardt. GitHub #115.
• gRPC 1.35.0RC1
  - gRPC Core 1.35.0 update - Removed zend_hash_destroy() from postfork handler #24891
• yac 2.3.0
  - PHP8 Supported
• yaf 3.3.0
  - PHP8 Supported - Fixed issue #508 (Route::addConfig take action as module wrongly) - Fixed issue #509 (getViewpath return NULL) - Fixed issue #513 (supports of custom camel MVC name) - Fixed issue #518 (setRediect not working)
• swoole 4.6.0
  Backward compatibility Break --- * Removed the maximum limit of session id, never repeat (#3879) (@matyhtf) * Disabled unsafe function when use Coroutine, including pcntl_fork/pcntl_wait/pcntl_waitpid/pcntl_sigtimedwait (#3880) (@matyhtf) * Enabled coroutine hook by default (#3903) (@matyhtf)

  Remove

  • No longer support PHP-7.1 (swoole/swoole-src@4a963df) (swoole/swoole-src@9de8d9e) (@matyhtf)

  Deprecated

  • Marked the Event::rshutdown() as deprecated, please use Coroutine::run instead (#3881) (@matyhtf)

  New APIs

  • Supported setPriority/getPriority (#3876) (@matyhtf)
  • Supported native-curl hook (#3863) (@matyhtf) (@huanghantao)
  • Supported object style callback parameters for Server, off by default (#3888) (@matyhtf)
  • Supported ext-sockets hook (#3898) (@matyhtf)
  • Supported duplicate header (#3905) (@matyhtf)
  • Supported SSL sni (#3908) (@matyhtf)
  • Supported hook stdio (#3924) (@matyhtf)
  • Supported capture_peer_cert option for stream_socket (#3930) (@matyhtf)
  • Added HttpRequest::create/parse/isCompleted (#3938) (@matyhtf)
  • Added HttpResponse::isWritable (swoole/swoole-src@db56827) (@matyhtf)

  Enhancement

  • All time accuracy of Server changed from int to double (#3882) (@matyhtf)
  • Added poll EINTR check for swoole_client_select (#3909) (@shiguangqi)
  • Added coroutine deadlock detect (#3911) (@matyhtf)
  • Supported closing the connection in another process with server base mode (#3916) (@matyhtf)
  • Optimized send to worker from master, reduced memory copy (#3910) (@huanghantao) (@matyhtf)

  Fixed

  • Pop Coroutine::Channel data when channel is closed (swoole/swoole-src@960431d) (@matyhtf)
  • Fixed memory error when use JIT (#3907) (@twose)
  • Fixed port->set() dtls compile error (#3947) (@Yurunsoft)
  • Fixed connection_list error (#3948) (@sy-records)
  • Fixed ssl verify (#3954) (@matyhtf)
  • Clear all columns when incr and decr (#3956) (@matyhtf) (@sy-records)
  • Fixed failed to compile with LibreSSL 2.7.5 (#3962) (@matyhtf)
  • Fixed undefined constant CURLOPT_HEADEROPT and CURLOPT_PROXYHEADER

  Kernel

  • Ignored SIGPIPE signal by default (swoole/swoole-src@9647678) (@matyhtf)
  • Supported running php and c coroutines at same time (swoole/swoole-src@c94bfd8) (@matyhtf)
  • Added TEST(coroutine_base, get_elapsed) (#3961) (@luolaifa000)
  • Added TEST(coroutine_base, get_init_msec) (#3964) (@luffluo)

Oops! Dealing with Your Freelance Mistakes

Among the harshest realities of being a freelance web designer (and a human) is that we’re bound to make mistakes. None of us can escape that fact. Therefore, we may as well accept it.

Still, there are major differences in the severity of the mistakes we make. A small misspelling isn’t quite the same as bringing down an entire website with a buggy piece of code. The same goes for the construction worker who merely forgot to install a light bulb, rather than failed to shore up that wall. Some are easier to correct and, thus, more easily forgiven.

Then there is the way we handle a given faux pas. Do we own up to it? Do we pretend it never happened? How do we react when a client calls us out?

Learning to deal with mistakes is part of the secret to long-term success for web designers. And, as someone who has made more than their fair share of mess-ups, I can attest to what works and what doesn’t.

Here are a few lessons I’ve learned about making things right again.

The Web Designer Toolbox

Unlimited Downloads: 1,000,000+ Web Templates, Themes, Plugins, Design Assets, and much more!

Web Templates

2,000+ Templates

Newsletter Templates

270+ Templates

Dashboard Templates

150+ Templates

WordPress Themes

1,200+ Themes

WordPress Plugins

550+ Plugins

Mockup Templates

8,200+ Templates

Start Downloading Now!

First, Understand What Happened

The funny thing about mistakes is that we don’t always immediately recognize them. It may be hours, days, weeks or months before one makes itself known to you. Therefore, its origins may be difficult to figure out.

When it’s something simple like a misspelled word, you’ll likely be able to track down what happened (Side Note: It’s always a good idea to proofread what a client sends you). But other issues can be much harder to trace. You may have to pore over code or user logs to get the necessary clues.

Why is it important to gain an understanding of what happened? For one, this information can help prevent a similar event in the future. That’s why we talk about learning from our mistakes, after all.

On the other side of the coin, it’s also worth knowing just whose mistake it was. In some instances, you may be the culprit. But clients and software vendors may also be to blame.

To be clear, it’s not really about assigning blame to someone. Rather, the idea is to simply understand the problem. That way, you can take preventative measures. It’s also useful in the event you have to defend yourself against an accusation.

Best of all, you’ll sleep better knowing exactly what went wrong. This type of knowledge is crucial for getting some peace of mind.

To Report a Mistake…or Not

Honesty is generally the best policy. And, let’s face it, there are certain mistakes that you couldn’t hide if you wanted to. A mishap that causes a site to go down isn’t so easy to sweep under the rug.

That aside, not every single mistake is worth reporting. This is particularly the case when the issue and impact are relatively small.

Consider an update to an eCommerce website where you’ve posted the wrong product image. If you immediately discovered the mix-up and rectified it, you probably don’t have to worry about letting your client know.

Of course, the bigger the impact, the more compelling a case for filing a report. If it’s something that a customer may have noticed or has the potential to hurt sales, that information should be shared.

It’s also worth considering both your own conscience and your client’s personality. Some people want to be informed about every step (good or bad), while others aren’t so concerned. At the same time, you might find yourself wanting to tell every detail just to make sure things are out in the open.

Ultimately, this is a judgement call – choose wisely!

Dealing with the Aftermath

Cleaning up after a mistake can be a multifaceted process. What’s involved really depends on the type of issue and the impact it has had on your project.

First and foremost is rectifying the design and technical aspects. Hopefully it’s something you can fix-up without too much trouble. At the very least, you should have backups of all key files on hand. This will allow you to revert to a previous version should the situation call for it.

The scariest part can often be discussing the issue with your client. No one likes to get called out. But, in my experience, most people are both understanding and forgiving. You just need to give them a chance.

The best approach is to calmly explain what happened in layman’s terms. You don’t have to go into every last detail unless your client asks. A general overview will usually be enough.

From there, mention any steps you can take to ensure the mistake doesn’t happen again. Sometimes a client has a role to play as well. For example, if their request wasn’t immediately clear and you changed the wrong thing – let them know. Better communication (not to mention asking questions) is often the best way to avoid mishaps.

Overall, this is an area where a strong designer-client relationship can make a difference. Mutual respect and trust enable you to work through these inevitable ups and downs.

Take Charge of Your Mistakes

Perhaps the biggest lesson here is to take charge of whatever situation you find yourself in. This will demonstrate both character and competence. Clients will respect you for it and you’ll gain some inner peace as well.

When you’re in a position to impact a project (positively or otherwise), a certain amount of leadership is required. Therefore, stand up and take the appropriate actions when you make a mistake. By rising to the challenge, you’ll gain the confidence you need to keep moving forward.

The post Oops! Dealing with Your Freelance Mistakes appeared first on Speckyboy Design Magazine.

Xdebug Update: December 2020

Truncated by Planet PHP, read more at the original (another 629 bytes)

Letter to a young Scrum Master

Yes, it's a terrifying role

So that's it, you have passed the certification for Scrum Master and it is time for you to join the team and play the role. You are terrified, and I understand why. After all, you're lucky we've spared some budget for this role and you'd better make the team perform better right away so your position is maintained. All eyes on you. If you don't make it, we give it all back to the almighty Project Manager. In the spotlight of all these expectations, here is an invitation to take a step back and relativize.

It's not about you, it's about the team

Most importantly, it is not about you, and will never be. It is about the team. So do not carry its destiny upon your shoulders. All you will ever do is serve them and hold a mirror to them. That's it. You have to walk with them, not ahead of them. Your angle is the one of curiosity: "Oh, have you noticed that? What do you think about it?". Naive is powerful, because it blows away all preconceptions. You can, over and over, invite your team to look at the status quo with a fresh angle, which may inspire them to take action, or try new things (and follow up on them). If you've managed that, your job is done.

Start from where the team is

It is also a bad idea to go in with an upfront plan of how you want to "change how things are run". Chances are there are many assumptions in your head, which may be completely off. Instead of bulldozing your way into the team, blasting and criticizing whatever is present, I urge you to think that whatever is in place has been put in place by professionals. The way the team functions today is how it has best overcome problems so far, so respect that. I'll quote the Kanban principle: "Start from where you are". And from then, lead the team to experiment, little by little. It may come a long way.

Don't wait to be ready

The polar opposite of this attitude is also very tempting. It is to remain paralyzed. "I don't feel ready". Who does? While it is certainly a good thing to attend a course and obtain a certification, there are enough books, articles and conferences on Scrum and Agile to fill several lifetimes. For the benefit of your team, don't wait until you've read them all. Practice is going to be your teacher. The best there is. Just like the team, you are going to do the best you can, day after day, and for sure it's not going to be perfect...

Look for criticism

... So there will be criticism. That is great news. If nobody says anything, that means everybody thinks you're beyond the point of recovery and it's not even worth it anymore to give feedback. Constructive criticism is your ally in doing a better job for your team. I even advise you to actively seek feedback. There are retrospective activities tailored just for that, such as "Build Your Own Scrum Master". Make it a game for the team. That way, you show that though you take the role seriously, you certainly do not take yourself seriously.

About today

So, what about today? Day One? Well, two postures I've previously written about are always available: The Servant and The Mechanic. As a servant, there's probably a hand you can lend to the team right now. Ask around, and remember, a chore is not a chore. It's a chance to lead by example. If you pull your finger out for your teammates, you'll not only shine but you'll also inspire them to do it more as well. As a process mechanic, have a look at the team's Scrum. How is the next sprint coming along? Is the backlog prioritized? If you have chosen User Stories to express needs, are there enough of them in a ready state? What does "Ready" mean for your team? Those are great conversation starters. Dive in. And if anything's off, investigate, don't blame.

Get accompanied on the journey

Sure, all of this is still a handful. But you don't have to go it alone. There is a tremendous global community of practice and many local ones too. Don't be afraid to check out scrum.org forums, browse meetup.com for groups near you – or far away from you, as remote work has made the world even flatter than before. If there are several Scrum Masters in your organization, hook up with them, set up weekly coffees to exchange your war stories. And if you feel like getting accompaniment on your journey, don't hesitate to reach out. Whether it is me or one of my colleagues from the Liip coaching team, it would be with pleasure to walk along with you.

An Early Look at Full Site Editing in WordPress

Here’s an existential question for web developers: How much separation should there be between a website’s content management system (CMS) and its design?

For a lot of the DIY services out there (Wix, Squarespace, etc.), just about every facet of a website can be edited visually. Whether it’s content, design or layout, you can tweak to your heart’s content. And you don’t need to understand code to do so.

But, save for some code-free page builder products, WordPress has traditionally stayed away from a full-blown site editor. The theme customizer allows users to change certain aspects of a theme – but only those defined by its developer.

That’s about to change. Full site editing (FSE) will allow the Gutenberg block editor to be used for editing the entire website – theme and all.

This newfangled feature may just revolutionize what is possible with a WordPress theme. With that, I wanted to take an early look at what it can do. Here’s what I found…

Setting up Full Site Editing in WordPress

As of this writing, full site editing has not been merged into WordPress core. It is a beta feature available through the Gutenberg plugin. So, I’ll grab the plugin and activate it first.

Then there’s the matter of finding a compatible theme. Q is the first WordPress theme that supports FSE and will serve as a canvas for this experiment. Having installed and activated the free theme, we can now take a look at what it does.

One other item to note: I’m doing this all on a local install of WordPress. There’s quite a lot to be tested and bugs to be fixed when it comes to full site editing. Therefore, it’s not ready for a production environment just yet. Test accordingly!

Initial Observations

Upon activating the Q theme, there are a couple noticeable differences in WordPress. On the back end, there is now a Site Editor entry on the menu. And when browsing the front end while logged in, an Edit Site link is displayed on the admin bar. Oh, and there’s also a warning notification about full site editing being experimental (we’ll just ignore that one).

The theme itself is pretty barebones – which is ideal. This provides us with an easier path to customize. When you think about it, you probably wouldn’t want to tear down an intricate design, only to build it back up into something else. Less is indeed more.

Peeking Inside the Site Editor

Now, about that site editor. Clicking into it opens up the Gutenberg block editor. But this time it’s more than just a standard blank page. Instead, I now have access to everything – header, navigation (through the experimental Navigation block), content area and footer.

As expected, making changes to any of these items is a matter of clicking into a block and getting to work. Individual blocks can be transformed to something else, edited or even deleted. Blocks can also be repositioned. Placing the navigation menu above the site’s title, for example, was a breeze. The same goes for replacing the single-column title heading with a multi-column layout.

But there’s more. Click on the WordPress logo on the upper left of the screen and you’ll open up the site editor’s sidebar. There, you can view and create theme templates (like the site’s index or posts template) or template parts (such as the header and footer). Note that you can also get to these items through the Appearance menu within WordPress. There’s also a way to get around to the site’s pages, posts and taxonomies.

What’s really nice here is that you have the option to isolate just the template parts you want to edit. If I pull up the header from Theme > Template Parts, that’s all I see in the block editor. But if I’d rather edit it within the context of the entire theme, I can just stay on that initial site editor page.

Creating New Templates

If you’re familiar with the Gutenberg block editor, creating new theme templates will be rather simple. The process is very much the same as crafting any other page or post. Create your desired layout using the available blocks and save – that’s it!

One thing to note is that, at this point, it appears custom templates will need to follow the WordPress template hierarchy naming conventions. That is, the slug of a custom template should match the name of its corresponding purpose within your theme (without the .php at the end).

For example, if you want to build a template to be used on your home page, its slug should be named front-page. Want to target the About Us page (yoursite.com/about-us/)? A template with the slug of page-about-us will do the trick.

The templates are available for download via the settings menu in the upper right of the editor. This allows you to manually save templates to your device and then upload to the server, protecting you from any potential mishaps.

Utilizing Template Parts

As previously mentioned, WordPress full site editing lets us edit and create template parts. This includes the site’s header and footer, but there are plenty of other possibilities.

Template parts can be created and then included into any template via a block. You can also add a template part to a specific page or post as well.

This might come in handy for times when you want to add a specific bit of content across several pages or posts types.

For example, think about a featured posts block that you want to display on both your individual posts and archive pages. Or perhaps there’s a navigation menu that you only want to appear when one or more specific templates are used.

Template parts are a means to set this up without the need for advanced techniques like conditional logic.

Questions for the Future of WordPress Themes

Overall, I felt positive about this experience with full site editing. There is still a long way to go in terms of squashing bugs and improving usability. Theme support is also going to be a big hurdle. But this has the potential to be a very useful feature.

Still, there are some questions that come to mind:

Who Is Full Site Editing Aimed At?

One of the overarching arguments for the Gutenberg block editor was that it was necessary to maintain relevance. Competitors in the DIY market have a more visual approach to building sites and WordPress had fallen behind.

With that, it makes sense that full site editing would be aimed at users who: a) don’t know or don’t want to utilize code; and b) want access to most (if not all) elements of their website.

What’s in It for Web Designers?

There are some benefits. Opening up a header, for example, may allow a client to quickly update a new phone number or address. This could save designers from dealing with very basic changes.

Yet there are going to be some things web professionals will want to lock down. Client-proofing a site is often done to protect against breakage. Layouts and functionality are essentials that we’d rather not take chances with.

Let’s hope that there are ways to easily exercise fine-grain control over what can and can’t be edited in the back end – like the existing theme customizer does. Otherwise, this is going to be one more potential nightmare to worry about.

How Will Full Site Editing Affect the Commercial Theme Market?

This will be fascinating to watch. Right now, it appears that very few themes have even been customized for Gutenberg. They are still relying on third-party page builder plugins for advanced layouts. And some products, like Divi and Beaver Builder, already have their own full site editing capabilities.

Therefore, don’t be surprised if adoption of full site editing is slow. Theme developers are unlikely to jump on the bandwagon until there is both demand and a clear indication of how they can benefit. Not to mention that a lot of existing features will need to be refactored.

In my view, developers will need to implement this in a way that increases flexibility for users while also minimizing risk of breakage. That could take the form of offering premade (and partially locked down) templates and letting users select which ones they want. But we are still very early in the game.

A More Seamless WordPress

So much of the WordPress ecosystem is piecemeal. Grab a theme from here, a plugin from there (and there and there) and try to make it all fit together. This is part of its appeal and has worked remarkably well.

But the design experience hasn’t quite benefitted from that flow. The look and layout of a theme has always been separated in some way. Whether it means hacking templates or using the theme customizer, there is a lot of running around involved.

Love it or hate it, full site editing is a step towards unifying the design process. With it, everything can be crafted in a single location within a single UI. It’s a more seamless experience, and one that should benefit a lot of users.

The post An Early Look at Full Site Editing in WordPress appeared first on Speckyboy Design Magazine.