Free PHPFree PHP scripts classes and info

Community News: Latest PECL Releases (06.30.2020)

Latest PECL Releases:

• uopz 6.1.2
  - make UOPZ compatible with Xdebug again (2.9.4+ required)

• redis 5.3.0RC2
  phpredis 5.3.0RC2

  This release contains initial support for Redis 6 ACLs, LZ4 compression, and many more fixes and improvements.

  You can find a detailed list of changes in Changelog.md and package.xml

  A special thanks to BlueHost for sponsoring ACL support o/

  • Sponsors ~ Audiomack - https://audiomack.com ~ BlueHost - https://bluehost.com ~ Redis Cache Pro for WordPress - https://wprediscache.com ~ Avtandil Kikabidze - https://github.com/akalongman

  phpredis 5.3.0RC2

  ---

  • Fix LZ4 configuration and use pkg-config if we have it [df398cb0] (Remi Collet)
  • Make sure persistent pool ID is NULL terminated [0838b5bd, 57bb95bf] (Michael Grunder)
  • Run LZ4 tests in Travis [3ba3f06d] (Michael Grunder)

  phpredis 5.3.0RC1

  ---

  • Support for Redis 6 ACLs [a311cc4e] (Michael Grunder)
  • LZ4 Compression [04def9fb] (Ilia Alshanetsky)
  • Support for new Redis 6 arguments (XINFO FULL, SET KEEPTTL) [a0c53e0b, f9c7bb57] (Michael Grunder, Victor Kislov)
  • Support for TLS connections [890ee0e6, b0671296] (Pavlo Yatsukhnenko)
  • New option Redis::SCAN_PREFIX, Redis::SCAN_NOPREFIX [e80600e2] (Pavlo Yatsukhnenko)
  • Configurable unit test authentication arguments [e37f38a3, 201a9759] (Pavlo Yatsukhnenko, Michael Grunder)
  • Improved cluster slot caching mechanism to fix a couple of bugs and make it more efficient. [5ca4141c] (Michael Grunder)
  • Stop calling Redis constructor when creating a RedisArray [e41e19a8] (Pavlo Yatsukhnenko)
  • Use ZEND_LONG_FMT instead of system long [5bf88124] (Michael Grunder)
  • Use long for SCAN iteration to fix potential overflow [f13f9b7c] (Victor Kislov)
  • Fix config.m4 to test for the variable $PHP_REDIS_JSON and not the literal PHP_REDIS_JSON [20a3dc72] (Mizuki Nakano)
  • Fix compiler warnings [b9b383f4, 215828e] (Remi Collet), Pavlo Yatsukhnenko)
  • Avoid use-after-free of RediSock [8c45816d] (Pavlo Yatsukhnenko)
  • Fixed ZADD arginfo [a8e2b021] (Pavlo Yatsukhnenko)
  • Store AUTH information in flags RedisSock rather than duplicating information. [58dab564] (Pavlo Yatsukhnenko)
  • Refactor redis_sock_get_connection_pool logic. [73212e1] (Pavlo Yatsukhnenko)
  • Updated documentation to show LPUSH and RPUSH are variadic and fixed DEL documentation. [92f8dde1] (Michael Grunder)
  • Authenticate in redis_server_sock_open [4ef465b5] (Pavlo Yatsukhnenko)
  • Dynamically include json.so in unit tests based on configuration [0ce7ca2f] (Michael Grunder)
  • Update save_path logic in Redis Cluster session unit tests [dd66fce] (Pavlo Yatsukhnenko)
  • Refactoring various bits of logic [bbcf32a3, a42cf189, 460c8f29, b7f9df75] (Pavlo Yatsukhnenko)
  • Use the portable ZEND_LONG_FORMAT family instead of C format specifiers [b9b383f4](Remi Collet)
  • PHP 8 compatibility [9ee94ca4, 7e4c7b3e] (Pavlo Yatsukhnenko)
  • Refactor PHPREDIS_GET_OBJECT macro [d5dadaf6, 190c0d34] (Pavlo Yatsukhnenko)
  • Fix documentation showing lPush and rPush are variadic [6808cd6a] (Michael Grunder)
• redis 5.3.0RC1
  phpredis 5.3.0RC1

  This release adds the first round of support for Redis 6 functionality including, most importantly ACLs. Other Redis 6 functionality is included as well such as KEEPTTL and XINFO FULL command support.

  Aside from the Redis 6 functionality this releasae contains many bugfixes and improvements.

  • Sponsors ~ Audiomack.com - https://audiomack.com ~ BlueHost.com - https://bluehost.com ~ Redis Cache Pro for WordPress - https://wprediscache.com/ ~ Avtandil Kikabidze - https://github.com/akalongman

  ---

  • Support for Redis 6 ACLs [a311cc4e] (Michael Grunder)
  • LZ4 Compression [04def9fb] (Ilia Alshanetsky)
  • Support for new Redis 6 arguments (XINFO FULL, SET KEEPTTL) [a0c53e0b, f9c7bb57] (Michael Grunder, Victor Kislov)
  • Support for TLS connections [890ee0e6, b0671296] (Pavlo Yatsukhnenko)
  • New option Redis::SCAN_PREFIX, Redis::SCAN_NOPREFIX [e80600e2] (Pavlo Yatsukhnenko)
  • Configurable unit test authentication arguments [e37f38a3, 201a9759] (Pavlo Yatsukhnenko, Michael Grunder)
  • Improved cluster slot caching mechanism to fix a couple of bugs and make it more efficient. [5ca4141c] (Michael Grunder)
  • Stop calling Redis constructor when creating a RedisArray [e41e19a8] (Pavlo Yatsukhnenko)
  • Use ZEND_LONG_FMT instead of system long [5bf88124] (Michael Grunder)
  • Use long for SCAN iteration to fix potential overflow [f13f9b7c] (Victor Kislov)
  • Fix config.m4 to test for the variable $PHP_REDIS_JSON and not the literal PHP_REDIS_JSON [20a3dc72] (Mizuki Nakano)
  • Fix compiler warnings [b9b383f4, 215828e] (Remi Collet), Pavlo Yatsukhnenko)
  • Avoid use-after-free of RediSock [8c45816d] (Pavlo Yatsukhnenko)
  • Fixed ZADD arginfo [a8e2b021] (Pavlo Yatsukhnenko)
  • Store AUTH information in flags RedisSock rather than duplicating information. [58dab564] (Pavlo Yatsukhnenko)
  • Refactor redis_sock_get_connection_pool logic. [73212e1] (Pavlo Yatsukhnenko)
  • Updated documentation to show LPUSH and RPUSH are variadic and fixed DEL documentation. [92f8dde1] (Michael Grunder)
  • Authenticate in redis_server_sock_open [4ef465b5] (Pavlo Yatsukhnenko)
  • Dynamically include json.so in unit tests based on configuration [0ce7ca2f] (Michael Grunder)
  • Update save_path logic in Redis Cluster session unit tests [dd66fce] (Pavlo Yatsukhnenko)
  • Refactoring various bits of logic [bbcf32a3, a42cf189, 460c8f29, b7f9df75] (Pavlo Yatsukhnenko)
  • Use the portable ZEND_LONG_FORMAT family instead of C format specifiers [b9b383f4](Remi Collet)
  • PHP 8 compatibility [9ee94ca4, 7e4c7b3e] (Pavlo Yatsukhnenko)
  • Refactor PHPREDIS_GET_OBJECT macro [d5dadaf6, 190c0d34] (Pavlo Yatsukhnenko)
  • Fix documentation showing lPush and rPush are variadic [6808cd6a] (Michael Grunder)

Interview with Sammy K. Powers

Interview with Nils Adermann and Jordi Boggiano

This episode is sponsored by
Ring Central Developers

The post Interview with Nils Adermann and Jordi Boggiano appeared first on Voices of the ElePHPant.

The 5 Biggest Pains in Website Maintenance

As the web has evolved over time, website complexity has trended upward. Why? Technology has allowed us to do more than ever.

Between content management systems (CMS), code frameworks and other technological advancements, high-end functionality is at our fingertips. This has raised the bar in not only what we can achieve, but what our clients expect of us as well.

While this evolution has brought a lot of positives, it has also made website maintenance all the more difficult. It’s the result of so many disparate pieces being brought together. In some ways, it’s also the price of taking advantage of the latest and greatest techniques.

With that, let’s take a look at (in no particular order) five of the more painful maintenance-related issues that many modern websites face.

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!

Ever-Changing APIs

A lot of websites depend on third-party APIs these days. They enable us to connect with providers such as Google Maps, Mailchimp and virtually every social media network out there.

Each API is different and, as you might expect, have their own unique quirks. And they also release new versions that one might view as a double-edged sword.

On one hand, it’s great to see a particular API evolve and add new features. There is a downside, though. Sometimes these changes require us to update our own implementations. Failure to do so can lead to a broken feature.

As an example, several years ago Twitter made an API change that resulted in a lot of issues for third-party providers. More recently, Instagram’s updated API meant users had to reauthenticate their apps in order to display feeds on their website.

It can be a major pain to keep up with all of these changes for even one website. If you manage multiple websites that use various APIs, you may not find out about a change until it’s too late.

Abandoned or Poorly-Maintained Plugins

A healthy variety of plugins is part of what makes an open-source CMS thrive. If developers are out there creating new functionality for a platform such as WordPress, it becomes more attractive to new users.

But variety itself does not guarantee quality or even a lengthy existence. Because anyone can publish a plugin, that means living with a lot of uncertainty. As platforms evolve, a particular plugin may not come along for the ride.

For web designers and their clients, this results in occasionally having to reinvent the wheel a bit. If a plugin we’ve chosen is buggy, no longer maintained by its author or both, a replacement must be found.

The more complex the plugin, the more painful it is to replace. It’s not just finding a new plugin, however. Any customizations made around the previous one will have to be refactored.

The whole process could become expensive and time-consuming.

Web Hosting Nightmares

We depend so much on web hosts. How much? Think of it this way: no matter how well-built a website is, it can’t overcome substandard hosting.

And, when hosts don’t hold up their end of the bargain, things can quickly become a nightmare. Frequent outages, security holes or lackluster support make our jobs that much harder. Especially so, considering that web designers are often caught in the middle.

We’re the ones who are typically the go-between for our client and the hosting provider. It could mean lots of time waiting in a chat or (even worse) hanging on the phone for answers.

Meanwhile, the website in question may or may not be available. Good times.

Dealing with Old Websites

The longer you’re in this industry, the more potential you have for “old” projects to still be floating around the interwebs. Quite often, it’s for a client who is on a budget or just doesn’t see the need for a redesign.

While an older site in itself isn’t a problem, the way it was built could be. Designers and developers often learn through experience. The techniques we used five years ago are likely miles away from how we’d do it today.

Thus, when one of these golden oldies needs maintenance, it can bring back every mistake we might have made on the project. It can make one kick themselves for not being able to predict the future.

On the bright side, digging through old code can make you better appreciate how far you’ve come.

The Mysteries of an Inherited Site

The oft-repeated “box of chocolates” reference from the film Forrest Gump could easily be applied to websites we inherit from other designers. You really have no idea what you’re dealing with until you examine every bit of code. And, even then, there can still be surprises.

What’s really fun is that an inherited site could leave you to work through every one of the items on this list. Abandoned plugins, outdated API calls, a poor hosting environment and other assorted issues could be lurking beneath the surface.

It takes a bit of bravery and a lot of patience to work on these types of projects. That’s why it’s important to charge accordingly for the challenge.

How Pain Can Lead to Growth

The above “pains” all have a few things in common. First, they are simply a part of our job – fun or not. While completely static websites still exist (and are making a comeback), there are still requirements for dealing with third-party apps and services. And no website is immune to hosting foibles.

In addition, each of these items provides an opportunity for web designers to learn and grow. The experiences we have can help us better understand how to deal with similar issues in the future.

That’s a good thing because the web’s complexities aren’t going away anytime soon.

The post The 5 Biggest Pains in Website Maintenance appeared first on Speckyboy Design Magazine.

Interview with Eric Poe & John Kary

Understanding what is wrong with meritocracy (part two)

Wow, quite a long time since I last wrote a blog post, which clearly hinted towards at least a part two one day. I recently started blogging elsewhere (more on that below) and kinda forgot about my old blog. Lately I have been getting spam on it though, which reminded me of this old post. So here comes part two. I should add that it didn?t really take me 5 years to mature my thoughts on this topic, it just ended up that I communicated those thoughts in other places.

That being said, one of the first learnings as I dove into this topic was that that step one was listening and learning. Basically I started expanding my twitter timeline to include more people specifically tweeting about the issues of diversity and inclusion. But also simply following more people with marginalized communities talking about tech.

I paid attention to the dynamics in discussions. But one of the most clear ways I finally realized and fully accepted that meritocracy is a myth came with this github study that showed that while acceptance rates of PRs from women were well below those of men, the acceptance rate of PRs from women that hid their gender even slightly outpaced those of men.

Due to this reality and the constant pins and needles on top of deliberate harassment, where keeping people from marginalized communities away and pushing those that made it out. We keep hearing about some pipeline problem but the real issue is that people from marginalized communities just see no point in staying. But obviously this is not the root cause. Just going from my personal experience at Liip, I can name more female developers that left IT than male, despite us having way more male developers. The good news here, better diversity is entirely possible in tech if we actually work hard on inclusion. This is why people say ?diversity means nothing without inclusion?.

So with those realizations, I came across a tweet in the spring of 2017 by Erin pointing out the issues with an all white men speaker line up for a SymfonyLive event in the US. I first started rattling off excuses (note sure if just in my head or also in tweets), but eventually this finally gave me the kick I needed to become active. So I started reading more blog posts on the topic. Thanks to Liip?s education budget for all its employees, I ended up hiring Sage Sharp to help me figure out the next steps Symfony should be taken and what pitfalls to avoid that could cause further harm.

I was very happy to find that the Symfony core team was very receptive to this topic. Later that year we formally launched the diversity initiative. More importantly the community, aside from a few voices, was supportive as well and willing to learn and welcome change. We focused on several topics, like improving the language in our docs and on the website. We worked on guides for how to give and receive feedback in issues and PRs but more importantly we also worked on making those a lived reality. Quickly contributors started approaching the diversity initiative for support when they encountered situations where they felt overwhelmed. This helped deescalate a lot of situations but also helped train many contributors.

We also implemented a diversity scholarship to allow people from marginalized communities, that could otherwise not attend, to come and join us at SymfonyCon. One of the biggest successes was the adoption of a code of conduct, which lays the groundwork for safety as we hope to grow our diversity. More importantly, we worked in defining reporting processes and get the CARE (Code of Conduct Active Response Ensurers) trained by Sage Sharp so that they are prepared properly to enforce the code of conduct and sure reporters are properly protected and supported. Overall from the feedback I have seen we have made significant strides in improving our communication and openness. You can read more about this on the Symfony blog.

That being said, all of this hasn?t fixed our demographic issues within the Symfony community. There are still only men on the core team. While there are more visible figures within the Symfony community with a diverse background, we are still miles away from even just reaching the demographic representation of the proprietary software world, let alone the world in general. This is a long long

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

Community News: Latest PEAR Releases (06.29.2020)

Latest PEAR Releases:

• Mail_Mime 1.10.9