Free PHPFree PHP scripts classes and info

Community News: Latest PECL Releases (10.20.2020)

Latest PECL Releases:

• mysql_xdevapi 8.0.22
  WL#14012: XProtocol -- support for configurable compression algorithms orabug #31364076: mysqlndx switch from C++14 to C++17, and all related orabug #31414039: mysqlndx apply std::string_view, remove MYSQLND_CSTRING orabug #30084547: improve zval wrapper orabug #31678047: prepared statements tests fail with the newest server orabug #31958145: some secure connection / TLS tests fail on el8-x86-64bit

• skywalking 4.0.0
  newly designed agent, modular design
• swoole 4.5.5
  New APIs --- + Added ProcessManager and alias ProcessProcessManager (swoole/library#eac1ac5) (@matyhtf) + Support HTTP2 server-side GOAWAY (#3710) (@doubaokun) + Added Comap() function (swoole/library#57) (@leocavalcante)

  Enhancement

  • Support http2 client unix socket (#3668) (@sy-records)
  • Set the worker status to SW_WORKER_EXIT when the worker process exits (#3724) (@matyhtf)
  • Add send_queued_bytes and recv_queued_bytes in Server::getClientInfo() (#3721) (#3731) (@matyhtf) (@Yurunsoft)
  • Support option of stats_file (#3725) (@matyhtf) (@Yurunsoft)

  Fixed

  • Fixed PHP8 build (zend_compile_string change) (#3670) (@twose)
  • Fixed PHP8 build (ext/sockets compatibility) (#3684) (@twose)
  • Fixed PHP8 build (php_url_encode_hash_ex change) (#3713) (@remicollet)
  • Fixed invalid conversion from 'const char*' to 'char*' for build (#3686) (@remicollet)
  • Fixed HTTP2 client over HTTP proxy is not working (#3677) (@matyhtf) (@twose)
  • Fixed PDO context data confusion (swoole/library#54) (@sy-records)

  Kernel

  • Code optimization (#3671) (#3689) (#3700) (#3701) (#3708) (#3718) (#3722) (#3723) (@matyhtf)
• datadog_trace 0.49.0
  ### Added - Add .gdbinit files from released PHP versions #996 - Support PHP 5.5 #1008, #1018, #1020, #1030, #1032 - Add PHP 5.4 support to PECL package #1019 - Add Levi and Luca as lead developers to package.xml #1025 - Close open spans on fatal errors #1028 - Attach fatal errors to all open internal spans #1034 - Experimental PHP 8.0.0 RC 1 support (Provided for testing only and not intended for use on production) #1027 #1036 #1041

  Changed

  • Enable the background sender by default on PHP 5.4 #991
  • Remove userland references to sandboxing #1003
  • Sandbox flush in limited mode on PHP 5.4 #1009
  • Defer loading of PDO, Memcached, Slim, WordPress, and Yii integrations until first usage #1006
  • Clear separation in testing of src/api vs src/DDTrace #1017
  • Harden curl integration #1024
  • Compile src/DDTrace/version.php into _generated.php to avoid loading it at runtime #1026
  • Disable instrumenting generators on PHP 5 #1050

  Fixed

  • Fix pecl-build for real releases #998
  • Properly group traces sent in batch during long running scripts #1029
  • Add back support for trace analytics to curl integration #1031
• xdebug 3.0.0beta1
  Wed, Oct 14, 2020 - xdebug 3.0.0beta1

  This is a BETA release, and not ready for production environments.

  Xdebug 3 has many changes. Please read the upgrade guide at https://3.xdebug.org/docs/upgrade_guide

  Xdebug 3 documentation is available at https://3.xdebug.org/docs

  ---

  • New features:

    • Implemented issue #1762: Introduce feature modes
    • Implemented issue #1793: Add xdebug.start_upon_error setting to cover the removed xdebug.remote_mode=jit feature.
    • Implemented issue #1797: Implement generic logging
    • Implemented issue #1801: Rename mode 'display' to mode 'develop'
    • Implemented issue #1831: Add diagnostics function xdebug_info()
    • Implemented issue #1833: Add links to documentation in diagnostic log
    • Implemented issue #1837: Support for associative variadic variable names (PHP 8)
    • Implemented issue #1841: Add support for PHP 8 'match' keyword

  • Removed features:

    • Implemented issue #1795: Deprecate PHP 7.1 support

    • Implemented issue #1786: Remove idekey value fallback to USER/USERNAME environment variable

    • Implemented issue #1809: Remove "overload_var_dump" setting

    • Implemented issue #1810: Remove collect_vars and xdebug_get_declared_vars()

    • Implemented issue #1812: Remove show_mem_delta setting

    • Implemented issue #1838: Remove collect_params setting, and always default it to "4"

    • Implemented issue #1847: Remove xdebug.remote_cookie_expire_time setting

  = Changes:

  • Implemented issue #1378: Unfortunate coupling of default_enable=1 and remote_mode=jit
  • Implemented issue #1773: Replace all xdebug.*_output_dir settings with xdebug.output_dir
  • Implemented issue #1785: Replace xdebug.remote_mode and xdebug.auto_trace with generic "start-with-request" setting
  • Implemented issue #1791: Replace xdebug.trigger, xdebug.trigger_value, with xdebug.start_with_request=trigger and xdebug.trigger_value
  • Implemented issue #1792: Change start_with_request=always/never to start_with_request=yes/no
  • Implemented issue #1794: Replace the filter's blacklist/whitelist with exclude/include
  • Implemented issue #1811: Remove xdebug.collect_includes setting and always include them
  • Implemented issue #1844: Add deprecation warning for removed and renamed configuration setting names
  • Implemented issue #1845: Rename xdebug.remote_{host,port} to xdebug.client_{host,port}
  • Implemented issue #1846: Rename setting xdebug.remote_timeout to xdebug.connect_timeout_ms
  • Implemented issue #1848: Change default Xdebug port from 9000 to 9003
  • Implemented issue #1850: Change array variable output in tracing to use modern [] syntax
  • Implemented issue #1856: Rename xdebug.remote_connect_back to xdebug.discover_client_host
  • Implemented issue #1857: Rename xdebug.remote_addr_header to xdebug.client_discovery_header

  • Improvements:

    • Implemented issue #1016: Support for pause-execution (Robert Lu)
    • Implemented issue #1680: Update var dumping routines to include relevant information for interned strings and immutable arrays
    • Implemented issue #1712: Add unit to profiler data types
    • Implemented issue #1743: Figuring out whether a call is a closure uses string comparisions instead of checking the ACC flag (Benjamin Eberlei)
    • Implemented issue #1752: Use a stack pool to manage stack entries instead of allocating and deallocating entries
    • Implemented issue #1755: Overload pcntl_fork() to prevent performance degradation by calling xdebug_get_pid often (Carlos Granados)
    • Implemented issue #1781: Include 'Xdebug' in max nesting level error message
    • Implemented issue #1783: Stacktrace needs vertical scrolling on small screens (Tobias Tom)
    • Implemented issue #1789: Provide PHP stubs for Xdebug's functions
    • Implemented issue #1807: Document Xdebug installation with yum and apt
    • Implemented issue #1813: Make sure that the xdebug_init_*_globals don't do more than they need to, and that init is only done when xdebug.mode != off
    • Implemented issue #1817: Switch filename storage from char*/size_t to zend_string*
    • Implemented issue #1818: Switch variable storage from char*/size_t to zend_string*
    • Implemented issue #1820: Increase time tracing precision (Michael Vo?íšek)
    • Implemented issue #1824: Allow Xdebug's mode to be set through an environment variable
    • Implemented issue #1825: Improve profiler performance by not calling fflush after every function (Michael Vo?íšek)
    • Implemented issue #1826: Reduce profiler memory allocation and call overhead
    • Implemented issue #1829: Switch to 10ns profiler resolution (Michael Vo?íšek)
    • Implemented issue #1832: If connect back host can not be contacted, fallback to remote_host/port
    • Implemented issue #1858: Only open/close log if there is an actual message to log
    • Implemented issue #1860: Allow xdebug.cloud_id to be set through an environment variable

  = Fixed bugs:

  • Fixed issue #1756: Php process won't exit after running connected to a client
  • Fixed issue #1823: Profiler generates negative data for memory usage
  • Fixed issue #1834: Return type must be bool in overloaded set_time_limit
• redis 5.3.2RC2
  phpredis 5.3.2RC2

  ---

  • Verify SET options are strings before testing them as strings [514bc371] (Michael Grunder)

  ---

  phpredis 5.3.2RC1

  This release containse some bugfixes and small improvements.

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

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

  ---

  • Fix cluster segfault when dealing with NULL multi bulk replies in RedisCluster [950e8de8] (Michael Grunder, Alex Offshore)
  • Fix xReadGroup() must return message id [500916a4] (Pavlo Yatsukhnenko)
  • Fix memory leak in rediscluster session handler [b2cffffc] (Pavlo Yatsukhnenko)
  • Fix XInfo() returns false if the stream is empty [5719c9f7, 566fdeeb] (Pavlo Yatsukhnenko, Michael Grunder)
  • Relax requirements on set's expire argument [36458071] (Michael Grunder)
  • Refactor redis_sock_check_liveness [c5950644] (Pavlo Yatsukhnenko)
  • PHP8 compatibility [a7662da7, f4a30cb2, 17848791] (Pavlo Yatsukhnenko, Remi Collet)
  • Update documentation [c9ed151d, 398c99d9] (Ali Alwash, Gregoire Pineau)
  • Add Redis::OPT_NULL_MULTIBULK_AS_NULL setting to treat NULL multi bulk replies as NULL instead of []. [950e8de8] (Michael Grunder, Alex Offshore)
  • Allow to specify stream context for rediscluster session handler [a8daaff8, 4fbe7df7] (Pavlo Yatsukhnenko)
  • Add new parameter to RedisCluster to specify stream ssl/tls context. [f771ea16] (Pavlo Yatsukhnenko)
  • Add new parameter to RedisSentinel to specify auth information [81c502ae] (Pavlo Yatsukhnenko)
• ds 1.3.0
  - ArrayAccess implemented consistently - IteratorAggregate implemented consistently - A few incorrect return types

Interview with Michael Lochemem

This episode is sponsored by
RingCentral Developers

The post Interview with Michael Lochemem appeared first on Voices of the ElePHPant.

Tips for Being a Good Design Mentor

One of the great aspects of being a web designer is in joining the supportive community of fellow professionals. There are just so many people who are willing to share their knowledge and help others learn.

There’s a lot of mentoring that goes on. The funny thing is that we don’t necessarily seek out these opportunities. It seems like they more often find us.

As such, it can be a challenge to advise another designer. Whether it’s general career advice, technical knowledge or even tips regarding client relations – you want to make a positive impact. Yet it’s also important to respect boundaries and provide others with a boost in self-worth.

That’s what being a good design mentor is all about. The following are some tips for helping others live their dream.

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!

Demonstrate Humility

When another web designer approaches you for advice, they likely have a good reason. They may well consider you to be successful and someone they can look up to. This in itself is actually quite an honor – one not to be taken for granted or dismissed.

Even if you aren’t able to answer every question or have the time to go in-depth, a polite response is in order. For example, pointing them to a blog post or other resource on a particular topic can be both helpful and expedient.

It’s also worth keeping in mind that we are all in different places when it comes to experience and skill level. Sometimes, we can let our ego get the best of us. That can lead to judging someone else because we perceive their skills as less worthy than our own.

However, we all start out from the lowest rungs of the ladder. Therefore, approach others with a sense of humility. Remember that you were once in that same position.

Combine Honest Critiques with Encouragement

Have you ever had someone ask your opinion about a website they’ve built? Perhaps it was their personal portfolio or a client project. If the result is less-than-ideal, giving feedback can be a bit like walking a tightrope.

The same can be said when looking at a snippet of code. Programming affords a lot of flexibility in terms of style, with each of us having a preferred technique. There may be times when what you see simply isn’t to your liking.

In these situations, aim for both honesty and encouragement. It’s OK to point out a mistake or omission, but do so with sensitivity. Everyone reacts differently to this sort of feedback and the wrong choice of words can be harmful.

One way to accomplish this is to add your own personal story to the critique. For instance, instead of bluntly telling someone their design doesn’t work in Firefox, explain the issue with an anecdote attached. You might point out that you had a similar issue with CSS Grid or whatever the culprit may be. Then, encourage them to dive back into their code and make adjustments.

This greatly humanizes the process of building a website. Your mentee will know that yes, you too have made mistakes and lived to tell about it. It’s a little thing, but can mean a whole lot to an inexperienced web designer.

Be an Attentive Listener

While part of being a mentor involves dispensing useful advice, don’t forget to listen as well. This is especially crucial when discussing career-oriented goals.

If you’re a successful freelancer or agency owner, it’s likely others will want pick your brain on the subject. They’ll want to know how you accomplished your goals, the challenges you faced and maybe even what’s next for your business.

But goals are very personalized. Not everyone is aiming for the same exact thing. Therefore, don’t assume the path will be the same for someone else.

How can you know for sure? By doing a lot of listening and asking the occasional question. The idea here is to find out what the other person wants to accomplish in their own journey.

Of course, your experiences can serve as a wonderful guide. But they should be put in the context of what your counterpart’s goals are. They’ll have the opportunity to learn from your triumphs and mistakes, while applying those lessons to their own career.

Give What You Can

For all its benefits, being a web designer can be a highly-stressful career. The day-to-day pressures of deadlines, changing technology and financial uncertainty is enough to wear any of us thin.

So, when someone is seeking our help or advice, it’s only natural to wonder if we have anything left to give. Here’s the thing: mentoring does not require your complete and total attention.

It’s not necessarily a matter of offering all of your free time to a designer looking to level up their game. You don’t even have to possess the answers to every question or sticky situation.

The reality is that most of us can’t make that sort of commitment. And your mentee isn’t likely to ask for one, either.

Instead, focus on what you are able to give. Whether it’s an extra five minutes between tasks or an hour on the weekend, it all counts and will be appreciated.

The Rewards of Being a Design Mentor

There’s nothing quite so rewarding as making a positive difference in someone else’s life. That is all the more reason to offer another designer the benefit of your unique experiences.

Plus, being a design mentor can also inspire you as well. It can refresh your creativity, improve your communication skills and even unlock other hidden talents.

So, don’t hesitate to connect with other web designers. After all, it’s a big part of what makes this community great.

The post Tips for Being a Good Design Mentor appeared first on Speckyboy Design Magazine.

New Free/Open Source Common Lisp Compiler: write computer programs in the Common Lisp language

A new software development suite has been added to the Free Common Lisp Compilers and Interpreters page. This one can generate native code for Windows. For those who don't know what I'm talking about here, Common Lisp is a general purpose, dynamic programming language that you can use to write computer programs.

The Grumpy Designer’s WordPress Plugin Pet Peeves

Believe it or not, a great WordPress plugin is something that can make me smile. If it’s particularly cool, helpful and time-saving, well, I might even become somewhat giddy.

For instance, when I first became a user of Advanced Custom Fields and Gravity Forms (and yes, I gladly pay to use each of them), I was blown away by what these plugins were capable of. Both opened up a new world of possibilities in terms of what I could offer clients. Beyond that, each had strong developer communities to extend their capabilities even further.

Still, WordPress plugins can also bring the opposite reaction. Some aren’t very reliable and shouldn’t be used in a production environment. Others work well enough, but have persistent bugs or features that bug the heck out of me. Worse still is when a formerly-useful product goes the way of the dinosaur.

In all, there are a number of plugin behaviors that have become pet peeves over the years. Here are a few of the more egregious – in one grumpy designer’s mind, at least.

An Endless Barrage of Notifications

There’s nothing quite like logging into WordPress and seeing a plugin notification to get the old heart racing. What could it be? Is something broken? Did I forget to renew that license? Oh, they just want me to buy something else. And give them a 5-star rating. Then click to learn more about their new-but-unrelated product.

We all need to make a living – I get it. Notifications are a means to an end, one of the few ways to get your message across in the dashboard.

If only one or two plugins did this, maybe the experience wouldn’t be so bad. But the issue is much more widespread. It seems like the majority of plugins are offering up notifications for things I don’t want to be notified about. Even commercial products that I’ve paid for are doing it.

The worst of all is when you take the time to dismiss a notification, only to see it come back the next time you log in. Isn’t once enough? I’ve felt less pressured on a used car lot. At least you can shoo the salesperson away if need be.

The result is a polluted dashboard, where important information is buried underneath sales pitches. Instead, maybe plugin developers could dedicate a separate page that includes whatever they want us to know (like the welcome screen used by WordPress itself)? It’s there if we want to see it. Otherwise, users don’t have to be bothered.

Official Plugins That Slowly Wither Away

Installing a new plugin is always an unpredictable experience. But it’s much easier to be confident when that plugin has a history of being well maintained. It’s also nice when you see its support forums showing regular engagement from the developer.

It’s understandable that some plugins just aren’t going to be maintained over the long haul. Yet, it’s particularly frustrating when that plugin is an official product that interfaces with a third-party service.

I’ve run into a couple of instances and, amazingly, they’re both competing products. I won’t name them except to say they are email delivery services (search the repository, they’ll be fairly easy to guess). As of this writing, neither plugin had seen an update in at least two years. Combined, they count nearly 200,000 active installations.

As you might imagine, a lot has happened in that span. For one, WordPress 5.0 and the Gutenberg block editor were introduced. Meanwhile, these plugins have become long in the tooth. In addition, some features no longer work as intended.

Both vendors continue to sell pricey services, but their official plugins languish. With the massive number of sites powered by WordPress, it seems foolish to ignore this market.

They should at least make an effort to keep things up. Even the occasional bug fix could go a long way towards instilling confidence.

Lackluster Support for Commercial Plugins

When it comes to functionality, there is a ton of diversity among WordPress plugins. They can be incredibly broad, do-it-all suites or tiny niche masterpieces. The level of support for these products can vary just as widely.

The truth is that some plugin authors provide higher levels of support. I’ve had great experiences with both free and commercial offerings. Developers who are prompt, thorough, polite and willing to help. They take their responsibilities very seriously.

Then there are those who, for one reason or another, just don’t provide that same level of service. Now, this is completely understandable when it comes to free plugins. These products are side gigs in many cases, and we shouldn’t reasonably expect anyone in that situation to respond immediately.

Where it becomes frustrating is in the commercial space. A plugin you have paid for should (in theory, at least) come with more attentive support. Unfortunately, that’s not always the case.

Among the worst practices are support tickets that go unanswered for days. It’s especially difficult when the issue is with an eCommerce-related plugin. A buggy store could be a real revenue killer and erode consumer trust. Being stuck waiting for a reply from technical support doesn’t help the situation.

Part of this speaks to the challenge of running a business. For companies that hire support technicians, it can be difficult to find and keep good people. Still, the bottom line is that poor service in this area can make you think twice about renewing that plugin license.

Honorable Mentions

Not every pet peeve is quite deserving of an entire section – but still worth a shout out. Here are a few that only feel like an occasional punch to the gut:

Commercial Plugin Update Fails: You enter the license key, activate it and everything’s great, right? Then, for reasons unknown, applying updates fail. Maybe not every time, but often enough to drive you crazy.

Once, Twice, Three Times an Update: A plugin releases an update and you successfully apply it. Woohoo! Except it contained an unintended issue that requires another update a half hour later. Especially fun when you manage multiple websites.

Disorganized Settings: When a plugin has a lot of settings, the process of tweaking them is so much easier if everything is well-organized. Hint: A massive, single page worth of hard-to-read options doesn’t fit the bill.

That’s it for this list! Have any of your own WordPress plugin pet peeves (or maybe “ungrateful user” pet peeves if you’re a developer)? Hit me up on Twitter and get it off your chest.

The post The Grumpy Designer’s WordPress Plugin Pet Peeves appeared first on Speckyboy Design Magazine.

Digital Identity slides from ZendCon