Michal Čihař - Blog Archives for phpMyAdmin

Weekly phpMyAdmin contributions 2017-W28

Last week was quite busy and that can be seen from number of issues. Some of them are coming from our error reporting server, where I've focused on the most frequently happening ones for last releases. Still there is about 30000 reports to handle there.

There were several fixes to our SQL parser as well, apparently it's already being used by some other tools, for example by php-sqllint, so we're getting more bug reports :-).

Handled issues:

Weekly phpMyAdmin contributions 2017-W26

Last week was really about solving bug and pull request. I've managed to go through many of long pending pull requests and most of them were merged either directly or with additional fixes.

I always feel bad when it takes too long to merge pull request, but most of them were actually waiting for some fixes which didn't arrive and I had to fix them on my own. This is often what happens to GSoC students pull requests once they realize they were not accepted in the end...

Handled issues:

Weekly phpMyAdmin contributions 2017-W25

Last week was a bit less intensive for me, still there were some bugs fixed.

Most of the time was spent on investigating one report from error reporting server. These errors do not come from our code, but we see them in thousands, so apparently something widely spread. The feature seems to come from DirectAdmin, but I've found occurrences elsewhere as well.

I think this exactly shows why you should upstream your patches - it would get proper upstream review and you would not have to maintain it over years (apparently they have five versions of the patch in their patches directory).

Anyway pretty much same will be possible to achieve with single line of configuration in the 4.8.0 release.

Handled issues:

Weekly phpMyAdmin contributions 2017-W24

Besides usual bug screening and pull requests merging, I've spent quite some amount in digging reports in our error reporting server and fixed the most visible ones.

The error reporting server collects errors happening in phpMyAdmin installations worldwide (this is opt-in reporting) and gives us insights where our users suffer most. Some of the errors are really weird and probably indicate PHP bug, but as we don't collect more information than is necessary, we really can not say for sure and we can not find person to reproduce the bug. Anyway if something has happened hundredth times on several installations, it's probably worth fixing in our code base.

Handled issues:

Weekly phpMyAdmin contributions 2017-W23

Last week was again quite busy on the issue tracker and pull requests. I start to think that I barely get to real development over handling flow of incoming reports and pull requests.

I've manged to fix some issues with parsing comments in SQL parser, which probably was not that much visible in phpMyAdmin, but was quite annoying when using SQL parser as library. Generally it seems that people are starting to use it, so at least one of our separate libraries is getting some user base outside phpMyAdmin.

Handled issues:

Weekly phpMyAdmin contributions 2017-W22

Last week was quite equally spread across our projects. I've spent time on motranslator, sql-parser, localized documentation and of course phpMyAdmin itself.

Generally it was mostly focused on going through issue trackers and pull requests to see what has happened in week I was offline.

Handled issues:

Weekly phpMyAdmin contributions 2017-W21

Last week was a bit shorter for me, but still there was quite some bugfixes done.

Most of the time was spent of fixing handling malformed mo files in motranslator, where the issues were reported by Emanuel Bronshtein. The library is now way more fault tolerant than it used to be if it gets corrupted file.

There was also quite some pull requests on phpMyAdmin to review and merge, but that seems to be usual in last weeks :-).

Handled issues:

Weekly phpMyAdmin contributions 2017-W20

Last week I was again quite active on development side bringing several improvements to master branch.

The biggest news is probably that phpMyAdmin no longer relies on eval() function. We've used it to run advisory rules on server configuration, but that is now done using Symfony ExpressionLanguage (which we anyway need due to motranslator).

When looking at things this does pull in, I've noticed that there is mbstring polyfill, which can be used instead of the one we ship (and was never completed). Thanks to this the mbstring dependency is now optional, but still recommended for performance reasons.

Another quite visible change is adding JSON metadata to our themes. Right now it covers basic things like theme compatibility and authorship, but more can be added later. This is also covered in our documentation.

Handled issues:

phpMyAdmin available in Packagist

For quite some time, we did provide Composer packages for phpMyAdmin, though they were available only in separate repository and not in the main Packagist repository, but now it's there!

The reason why we didn't do that was that it really doesn't integrate well with our release process - we release ready to use tarballs, while the VCS doesn't contain all things end users expect (eg. byte compiled localization files). Putting generated content to VCS didn't sound right and there is no option of using own tarballs on Packagist repo.

That's why we've ended up providing own channel with release tarballs. However this approach is not good either as that already bundles dependencies installable by composer, possibly causing problems when trying to upgrade these.

Therefore I've decided to generate separate VCS for composer packages. This way it doesn't pollute development VCS, but still Composer gets what it expects. The phpmyadmin/phpmyadmin is now using separate VCS and is updated daily using shell script. There might be some glitches during initial runs, so please report me any problems you see.

You can find more information on installing phpMyAdmin using Composer in our documentation.