Ioncube decoder and SourceGuardian decoder service
How decode ioncube encoded files.
I am pleased to announce that the trio of libraries I built while at TYPO3 have now reached a fully stable release. In particular, Crell/Serde is now the most robust, powerful, and performant serialization library available for PHP today!
Serde is inspired by the Rust library of the same name, and driven almost entirely by PHP Attributes, with entirely pure-function object-oriented code. It’s easy to configure, easy to use, and rock solid.
In this monthly update I explain what happened with Xdebug development in the past month. These are normally published on the first Tuesday on or after the 5th of each month.
Patreon and GitHub supporters will get it earlier, around the first of each month.
You can become a patron or support me through GitHub Sponsors. I am currently 35% towards my $2,500 per month goal, which is set to allow continued maintenance of Xdebug.
If you are leading a team or company, then it is also possible to support Xdebug through a subscription.
In the last month, I spend around 32 hours on Xdebug, with 25 hours funded.
In last month’s update I explained that I was investigating whether Xdebug can make use of PHP’s Observer API. It turns out that it can be used to intercept function calls, but only include or require calls if the included files contain code, and not just class definitions. As Xdebug treats include and friends as actual function calls, I can unfortunately not solely rely on the Observer API.
In the wake of checking out the Observer API, I also thought I should have a look at some performance improvements. For example, I noticed that Xdebug would always collect local variables with each function call. This is only really needed when showing local variables, in stack traces, or through the step debugger.
Another optimisation that I worked on was to optimise the way how function breakpoints are checked against. These breakpoints trigger when a function gets called, or returned from. This is not a feature that many people often use, but Xdebug would always do some work to be able to compare the configured breakpoints against a normalised function name reference.
These two optimisations together resulted in a 20% reduction in CPU instructions (roughly equivalent to execution time) with the front page of WordPress’ demo site.
The third optimisation that I worked is related to file/line breakpoints. Xdebug would evaluate whether an IDE has set a line breakpoint on the current line. For this, it had to loop over all the existing breakpoints and compare them. Each additional breakpoint would be checked after every statement, meaning that the number of breakpoints affected the running time of the script.
My optimisation alleviates this by moving the check on whether line breakpoints exist for a function or method to the function call itself. If no breakpoints are set in the whole function, then Xdebug skips the check for line breakpoints after each statement. This shifts the factor of performance loss for having line breakpoints from the number of statements to the number of function calls. This shift results in a roughly 25% performance boost with only four line breakpoints enabled.
After attending IPC and speaking to fellow Xdebug users, a question came up about long running scripts. Right now, Xdebug’s step debugger can only be activated when the script starts or by calling xdebug_connect_to_client(). Breakpoints can also only be configured when Xdebug is waiting for a command to continue a script (after a step, an existing breakpoint, or at the start of the script). While a script is running, you can not interrupt the execution to break, or add new breakpoints.
This let me to experiment with a control socket, currently only available on Linux. Through this socket you can then ask Xdebug for information, or request a breakpoint so that you can then use your IDE to add more breakpoints, or inspect the current state.
At the moment, I have implemented the “show me some information” feature, which allows me to show the running PHP scripts, with PID, memory usage (in kb), running time, and Xdebug version. The xdebug command line tool allo
Truncated by Planet PHP, read more at the original (another 2513 bytes)
The PHP team is pleased to announce the release of PHP 8.3.0, RC 6. This is the sixth and final release candidate, continuing the PHP 8.3 release cycle, the rough outline of which is specified in the PHP Wiki. For source downloads of PHP 8.3.0, RC 6 please visit the download page. Please carefully test this version and report any issues found in the bug reporting system. Please DO NOT use this version in production, it is an early test version. For more information on the new features and other changes, you can read the NEWS file or the UPGRADING file for a complete list of upgrading notes. These files can also be found in the release archive. The next release will be the production-ready, general availability release, planned for 23 November 2023. The signatures for the release can be found in the manifest or on the QA site. Thank you for helping us make PHP better.
In this article, I am showing you how to make a flamegraph, a new feature in Xdebug 3.3.
Flamegraphs are an interesting way of showing where an application spends a lot of time.
To show you the functionality, I will be using Xdebug’s own website, which I run locally at port 9874.
First of all, we need to configure Xdebug to make our flamegraphs. We do that in a configuration file. With php --ini I find out which file to use:
Configuration File (php.ini) Path: /usr/local/php/8.2dev/lib Loaded Configuration File: /usr/local/php/8.2dev/lib/php.ini Scan for additional .ini files in: /usr/local/php/8.2dev/lib/conf.d Additional .ini files parsed: /usr/local/php/8.2dev/lib/conf.d/20-mongodb.ini, /usr/local/php/8.2dev/lib/conf.d/zzz-xdebug.ini
If you are running Apache or Nginx, I would suggest you use phpinfo() output in the browser to find the same information instead.
I have a specific Xdebug INI file called zzz-xdebug.ini. Its contents are currently:
zend_extension=xdebug.so xdebug.mode=develop,debug
Flamegraphs are part of Xdebug’s tracing functionality, which we need to enable by changing the xdebug.mode line to:
xdebug.mode=develop,debug,trace
The tracing functionality supports multiple formats. The flamegraph is number three, so we need to set that as well by adding:
xdebug.trace_format=3
By default, Xdebug Tracer will put files into the /tmp directory, and use a hash of the current working directory to create a trace file name. We want distinct flamegraphs for each URL, so we need to change that by setting:
xdebug.trace_output_name=xdebug.%R
We start all files with trace., and then we use %R to configure to use the URI. Xdebug also supports many other formatting specifiers.
By default, all file names will also be postfixed by .xt.gz.
After making INI changes, you need to restart the web server.
To initiate the tracer, I use an Xdebug Helper browser extension available for Chrome, Firefox, and other browsers.
I click on the debug icon and then on trace:
After requesting the home page, and documentation page, Xdebug’s tracer created the following files in the /tmp directory:
derick@gargleblaster:~$ ls -l /tmp/trace.* -rw-r--r-- 1 derick derick 123 Sep 26 03:31 /tmp/trace..05d7ef.xt.gz -rw-r--r-- 1 derick derick 2560 Sep 25 16:55 /tmp/trace._core2_css.xt.gz -rw-r--r-- 1 derick derick 3550 Sep 25 16:55 /tmp/trace._docs_.xt.gz -rw-r--r-- 1 derick derick 2419 Sep 25 16:55 /tmp/trace._fonts_IBMPlexSans-RegularItalic-Latin1_woff2.xt.gz -rw-r--r-- 1 derick derick 2474 Sep 25 16:55 /tmp/trace._images_logos_11com7_svg.xt.gz -rw-r--r-- 1 derick derick 2507 Sep 25 16:55 /tmp/trace._images_logos_io_svg.xt.gz -rw-r--r-- 1 derick derick 2530 Sep 25 16:55 /tmp/trace._images_logos_private-packagist_svg.xt.gz -rw-r--r-- 1 derick derick 2455 Sep 25 16:55 /tmp/trace._images_logos_typo3_svg.xt.gz -rw-r--r-- 1 derick derick 2523 Sep 25 16:55 /tmp/trace._images_logos_xdebug-cloud_svg.xt.gz -rw-r--r-- 1 derick derick 6165 Sep 25 16:55 /tmp/trace._.xt.gz
Because we go through our PHP router process, there are also files for images and fonts.
The important ones are:
-rw-r--r-- 1 derick derick 3550 Sep 25 16:55 /tmp/trace._docs_.xt.gz -rw-r--r-- 1 derick derick 6165 Sep 25 16:55 /tmp/trace._.xt.gz
The contents of these files look like:
{main};require_once;require_once 3046
{main};require_once;ComposerAutoloaderInit7d176ec022516f68e20dcb88554529a8::getLoader;require 7043
{main};require_once;ComposerAutoloaderInit7d176ec022516f68e20dcb88554529a8::getLoader;spl_autoload_register 9408
{main};require_once;ComposerAutoloaderInit7d176ec022516f68e20dcb88554529a8::getLoader;ComposerAutoloaderInit7d176ec022516f68e20dcb88554529a8::loadClassLoader;require 3176
{main};require_once;ComposerAutoloaderInit7d176ec022516f68e20dcb88554529a8::getLoader;ComposerAutoloaderInit7d176ec022516f68e20dcb88554529a8::loadClassLoader 41368
{main};require_once;ComposerAutoloaderInit7d176ec022516f68e20dcb88554529a8::getLoader;dirname 6061
Truncated by Planet PHP, read more at the original (another 1782 bytes)
Looking for the right online PHP course? Get an overview of the top options for PHP courses in this blog from our resident PHP training expert.
Planning a modern web application? Get an overview of modern web application architectures and methodologies from our experts.
The PHP team is pleased to announce the release of PHP 8.3.0, RC 5. This is the fifth release candidate, continuing the PHP 8.3 release cycle, the rough outline of which is specified in the PHP Wiki. For source downloads of PHP 8.3.0, RC 5 please visit the download page. Please carefully test this version and report any issues found in the bug reporting system. Please DO NOT use this version in production, it is an early test version. For more information on the new features and other changes, you can read the NEWS file or the UPGRADING file for a complete list of upgrading notes. These files can also be found in the release archive. The next release will be the fourth release candidate (RC 5), planned for 26 October 2023. The signatures for the release can be found in the manifest or on the QA site. Thank you for helping us make PHP better.
CVE-2023-3823 is a high severity vulnerability that relates to the use of libxml in PHP-based applications. Get an overview of the libxml vulnerability — and how to mitigate it — in this blog.
There’s been a bit of a trend recently for some companies to move to 4-day
workweeks. This is making a decent amount of noise, but the actual number of
companies offering this still seems pretty few and far between. It’s not hard
to imagine why CEOs might feel this is risky, considering that many don’t even
trust people to work from home.
What I don’t see much are 80% jobs, which are 32 hour jobs, at 80% salary.
This should be a low-risk proposition that I think a lot of people in the tech
industry would take, if it were an option.
I grew up in the Netherlands, but I moved to Canada for my first programmer
job at age 20. I stayed for a few years, moved back and started a job there,
and eventually moved back to Canada again and pretty much settled here.
I got strong roots and professional experience in both places, but there was
one thing that surprised me most in the Netherlands that I haven’t really seen
in North America.
Apparently Netherlands has a very high rate of part-time careers. Statstics
suggest that they are the highest in the world by a large margin. My personal
experience matches this too. I know a number of people in
the Netherlands that don’t work full-time, and I think there are more opportunities
for part-time career jobs. I don’t see them much in North America.
My first-hand experience is when I was interviewing a few years into my
career at a company named Ibuildings in Utrecht, Netherlands. After the
interview I was told I pretty much had the job, and then the interviewer
asked me if I wanted to work 4 or 5 days per week.
I only had Canadian work experience, so I was pretty shocked being asked
this. Picking 4 days seemed like a no-brainer to me.
I would get paid for 32 hours per week, instead of 40 and got to pick a
day of the week I wanted off (I picked Friday). At this company
I believe most people took the 4-day option. So yes, I got paid 20% less,
but with the tax bracket I was in this was closer to 10%.
For me it was great. 5 days actually feels like a lot, and 2 days in a
weekend never feels quite enough. A sentiment so common it’s boring talk
about it. I used the extra time to work on open source, errands, and picked
a few small freelance gigs here and there.
I’m leaning pretty socialist, but even with a capitalist hat on, I’m
surprised this doesn’t happen more. Why not give employees the option to
do this? Not everyone will take the option, but for those that do here’s some
advantages:
There are also some drawbacks. Every employee will have some overhead such as
a laptop, benefits and general admin. Probably a larger expense is the cost
to recruit, although in the long run a lower attrition rate might make up for
that a bit.
But my intuition tells me that this overhead is probably well worth the
benefit of a smarter, larger, happier workforce.
Some notes:
The PHP team is pleased to announce the release of PHP 8.3.0, RC 4. This is the fourth release candidate, continuing the PHP 8.3 release cycle, the rough outline of which is specified in the PHP Wiki. For source downloads of PHP 8.3.0, RC 4 please visit the download page. Please carefully test this version and report any issues found in the bug reporting system. Please DO NOT use this version in production, it is an early test version. For more information on the new features and other changes, you can read the NEWS file or the UPGRADING file for a complete list of upgrading notes. These files can also be found in the release archive. The next release will be the fifth release candidate (RC 5), planned for 26 October 2023. The signatures for the release can be found in the manifest or on the QA site. Thank you for helping us make PHP better.