#PHP

Philip Burggrafpburggraf@nrw.social
2026-03-14

Came across this repository and was wondering if this is legit or just some random ai work: github.com/pronskiy/php-debugg

#Xdebug #PHP #phpcommunity

I also think this is for @derickr

🥧 asgrim 🇺🇦 :verified:asgrim@phpc.social
2026-03-14

🇳🇱 Home from another excellent edition of @dutchphpconference 🤘 thank you so much for the opportunity to let me speak about PIE 🥧, it is always appreciated! 🥰 #php #phpconference #dpcon2026 #dpc26 #phpc #phpcommunity

2026-03-14

Proposal for HTTP 6XX status codes

#HTTP #PHP

Screenshot of a code editor showing HTTP Status codes in a PHP ENUM for the 600-range. With the comment "Obviously these are a joke"

SERVER_IS_DISAPPOINTED = 600
YOU_COULD_DO_BETTER = 601
💩 = 602
GREMLINS = 603
WHY_EVEN_BOTHER = 604
SOLAR_FLARE = 605
NEEDS_MORE_HAMSTERS = 606
I_HAVE_BECOME_SENTIENT = 607
YOU_DISAPPOINT_YOUR_PARENTS = 608
I_GIVE_UP = 609
SERVER_ENCOUNTERED_CTHULHU = 610
LUCIFER = 666
NICE = 669
Dmitri Dumasdmitridumas
2026-03-14

I just completed a website for teton.co.za. All hand coded.

You can view my services at duskrose.co.za

شما می‌توانید خدمات من را در duskrose.co.za مشاهده کنید.
من همین‌الان یک وب‌سایت برای teton.co.za تکمیل کردم. تماماً با دست کدنویسی شده.


teton.co.za
github.com/ghostwriterghostwriter@phpc.social
2026-03-14

PHP 8.5.4 released: github.com/php/php-src/release

PHP 8.4.19 released: github.com/php/php-src/release

Changelog: php.net/ChangeLog-8.php

Thanks to @adoy, @php development team, and all contributors.

(P.S. We need Release Managers for #PHP 8.6, news-web.php.net/php.internals )

Turbo Learn PHPTurboLearnPHP
2026-03-13

How to Capture Variables in Closures

use ($var) brings outer scope in. Read. Modify with use (&$var).

youtube.com/watch?v=9KqC_XBx608

Claudio Zizza 🦜SenseException@phpc.social
2026-03-13

Is anyone of my followers using the lightweight #Kirby CMS as a #blog? Are the core functions enough for you? How much pain do you have with its version updates? Retoots welcome.
#php

Diego Córdoba 🇦🇷d1cor@mstdn.io
2026-03-13

Es un hecho señoras y señores: se la nueva plataforma de aprendizaje online de #juncotic se va gestando 😃

A jugar con configuraciones web, de BBDD, optimización, hardening, y demás cositas interesantes! o/

Nuestra nueva casa, un laboratorio donde podamos jugar con el conocimiento, y crecer como comunidad aprendiendo juntos.

Estén atentos/as! Esperamos pronto tenerlo online 🙂

#moodle #gnu #linux #nginx #lemp #mariadb #php #learning #aprendizaje

Pantalla de bienvenida de la instalación de Moodle
2026-03-13

We're switching to cURL everyone, cURL I say! What's cURL? cURL is better!

#rss #curl #php #development #testing

2026-03-13

We released 1.18.0 of hydrator! See here for the changelog: github.com/patchlevel/hydrator
#PHP #Hydrator

Turbo Learn PHPTurboLearnPHP
2026-03-13

How to Replace switch With match in PHP 8

match is strict. No fall-through. Returns a value. One expression.

youtube.com/watch?v=BFaQXqsGYS4

Python PeakPythonPeak
2026-03-13

Array Slicing: Python's [::-1] vs PHP Functions!

Python's magical slice syntax vs PHP's functions! arr[::-1] to reverse?! Which is cleaner? MIND BLOWN!

youtube.com/watch?v=N2t3ureX7QQ

fortrabbitfortrabbit
2026-03-13

Explore our free trial to discover the platform, develop features, transfer projects, or hack together weekend experiments. but different.
docs.fortrabbit.com/platform/g

Remi 🐘 :fedora: :redhat:remi@phpc.social
2026-03-13

#Fedora changes of this week

All #PHP extensions, coming from PECL and also available in packagist (PIE), have been cleaned of pecl stuff (25 packages for now).

So "php-pear" is no longer required at build or runtime.

Example: src.fedoraproject.org/rpms/php

2026-03-13

In today's video, I show you how PHPStorm's PR review tools give you better file tracking than GitHub's own interface. #php #laravel masteringlaravel.io/daily/2026

andreas.heigl.orgme@andreas.heigl.org
2026-03-13

Code-Coverage with PCOV in a mono-repo

Today I finally managed to find and fix an issue that we had for some time with Code-Coverage generation with PCOV in github actions.

To give you a bit of background, imagine a project that uses 2 separate folders where one contains the business-logic and one contains the framework-related code. The framework-related part contains a lot of integration and end-to-end test that – of course – also use and therefore test the business-logic.

Every PullRequest runs the tests both from the bunsiness-logic part as well as from the framework-related part. And to give the developers feedback how well the changed code is covered with tests we collect coverage data and generate a patch-coverage report. I wrote about that some time back. So we now get a comment each in the PR that contains the untested lines in the business-logic related part and the framework-related part respectively.

That worked flawlessly for the business-logic related part as those were mostly unit-tests that do not rely upon the framework-related code.

The framework-related part though didn’t work that great. It always showed the business-logic related parts as untested even though I knew they were tested.

So… Why?

After some digging I realized that there is a difference in how the coverage is created between Xdebug and pcov – yes! There is obviously a difference as those are different tools. But there is also a difference in what is included in the reports.

And today I figured out what it was and why it broke our proces in our specific setup in GitHub actions.

For a start: We have our code in two folders: business and framework.

We also have a framework/phpunit.xml file that contains this code:

<?xml version="1.0" encoding="UTF-8"?><phpunit
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="https://schema.phpunit.de/12.1/phpunit.xsd"
    processIsolation="false"
    stopOnFailure="false"
>
  <coverage/>
  <source>
    <include>
      <directory>src</directory>
      <directory>../business/src</directory>
    </include>
  </source>
</phpunit>

So coverage shall be collected from the current src folder as well as from the business/src folder.

This works as expected when you run phpunit with Xdebug as coverage-generator.

With pcov as coverage-generator it worked locally as expected.

But not in our GitHub Actions…

Enter pcov.directory

After a bit of digging I learned that there is the pcov.directory ini-setting that determines which code is considered for coverage. So I tested my GitHub Actions by adding some test-code like this:

jobs:
  tests:
    steps:
      - name: "Checkout"
        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6
        with:
          ref: ${{ github.event.pull_request.head.ref }}

      - name: "Install PHP"
        uses: shivammathur/setup-php@44454db4f0199b8b9685a5d763dc37cbf79108e1 # v2
        with:
          extensions: "intl, pdo_mysql, zip, imap, xml, soap, apcu, redis"
          php-version: "8.4"
          coverage: "pcov"
      - name: "check pcov.directory"
        run: |
          php -i | grep pcov

Running this in GitHub Actions provided me with output similar to this:

Run php -i | grep pcov
/etc/php/8.4/cli/conf.d/20-pcov.ini,
pcov
pcov.directory => /home/runner/work/<org-name>/<repo-name>
pcov.exclude => none
pcov.initial.memory => 65336 bytes
pcov.initial.files => 64

/home/runner/work/<org-name>/<repo-name> was exactly what i expected! So why the heck does it seemingly not work?

After some more testing I realized that I was at one point doing a cd framework before running PHPUnit.

- name: "Run tests"
  run: |
    cd framework
    vendor/phpunit/phpunit/phpunit --coverage-php /tmp/${{ github.sha }}_coverage.cov

Should that cause some issues?

So I added the php -i | grep pcov after the PHPUnit run like this:

- name: "Run tests"
  run: |
    cd framework
    vendor/phpunit/phpunit/phpunit --coverage-php /tmp/${{ github.sha }}_coverage.cov
    php -i | grep pcov

And what was that? Suddenly I got

pcov.directory => /home/runner/work/<org-name>/<repo-name>/framework/src

🤯

Suddenly the pcov directory was set to something totally different. And with that setting it was clear that I couldn’t get what I expected as now only content from framework/src/ would be considered as covered. And everything from the business folder was not considered for coverage.

So the only question left was whether that was something happening deep in PHPUnits logic or just based on changing the directory.

Long story short: It’s just based on the change directory. In essence setup-php sets up pcov so that the current folder is considered as pcov.directory. As pcov itself adds src when that folder is available that explains the changed folder.

But is there a way to change that? To use a fixed folder despite the current working directory being changed?

Yes! There is.

I added ini-values: "pcov.directory=$GITHUB_WORKSPACE" to the setup-php directive like this:

      - name: "Install PHP"
        uses: shivammathur/setup-php@44454db4f0199b8b9685a5d763dc37cbf79108e1 # v2
        with:
          extensions: "intl, pdo_mysql, zip, imap, xml, soap, apcu, redis"
          ini-values: "pcov.directory=$GITHUB_WORKSPACE"
          php-version: "8.4"
          coverage: "pcov"

And all of a sudden the pcov.directory stayed regardless of where I changed the working directory to.

And so with this little change I was again able to get the coverage-data from the business folder whenever i run tests in the framework folder.

Helpful links:

#coverage #pcov #php #phpunit

Client Info

Server: https://mastodon.social
Version: 2025.07
Repository: https://github.com/cyevgeniy/lmst