On the Snyk.io site they've announced the release of their State of Open Source Security Report for 2019. In this report they talk about packages and managers outside of the PHP ecosystem, but there's also plenty in there about general Open Source security, regardless of the technology used.

We’ve seen big technology players doubling-down on open source in 2018. In every registry we reviewed, we saw an increasing rate of open source libraries being indexed in every language ecosystem. This is to be expected, but the rate of growth may come as a surprise to many.

[...] In 2017 the CVE list reported more than 14,000 vulnerabilities, breaking the record for the most CVEs reported in a single year. 2018 continued the record-breaking streak with over 16,000 vulnerabilities reported.

We can see how open source package growth translates into user adoption when looking at the download numbers for various packages in different ecosystems.

They specifically cover packages in the Node.js, Python and Java worlds but the same principles apply to PHP and Composer packages too. There's a few other related posts that go into more detail on the vulnerability increases, the desire for Open Source developers to be security-minded and other topics. You can get all of the information in one place, though: the PDF version of the report.

As a maintainer of an open source project there are things that can help to make your role easier. One of them is encouraging useful issues being filed on the project with good information about the problem or suggestion. In this post to his site Sebastian De Deyne shares a few helpful hints on what can make for a good issue.

Maintaining a number of open source projects comes with a number of issues. Reporting a good issue will result in a more engaged approach from project maintainers. Don't forget: there's a human behind every project.

His suggestions include:

• as much detail as possible ("X is broken" isn't useful)
• having a single point or suggestion per issue
• being polite (remember, open source maintainers aren't often paid for this work)

His last point might be the most important: making a human connection. Sometimes it's easy to forget that there's a real person on the other end of the line. If you work with the person reporting the issue rather than just focusing on the technical parts it can make it an easier and more pleasurable process for all involved.

TutsPlus.com has posted the latest part of their "Building Your Startup with PHP" series following along with the creation of a "meeting planner" application based on the Yii2 framework. In this new article the focus is on collecting and managing user feedback and reports for a simple support system.

In this series, I'm guiding you through launching a startup from concept to reality using my Meeting Planner app as a real-life example. Every step along the way, I'll release the Meeting Planner code as open-source examples you can learn from. I'll also address startup-related business issues as they arise.

In this tutorial, I'm going to guide you through how I quickly and economically launched a support system and knowledge base for the application as well as some of the issues and alternatives I considered.

He starts with some of the third-party options he considered including Zendesk, Grove and Freshdesk. In the end he decided to go with the last option as it had the startup-friendly combination of a free account for small business and good functionality at that level. He covers their pricing levels, the signup process and the basic usage of the account and hooking it into Mailgun for sending/receiving emails. He also walks you through customizing the domain to match yours and updating the code to make the "Support" URLs match the new Freshdesk setup.

On the SquizLabs site they've shares the results of their coding conventions analysis of PHP projects using the PHP_CodeSniffer tool.

PHP_CodeSniffer, using a custom coding standard and report, was used to record various coding conventions across 193 PHP projects.

They've broken it down by the list of rules included in the default coding standards including:

• Array end comma
• Class defined in namespace
• Function has doc comment
• Adjacent assignments aligned
• CamelCase method name
• Line length
• Spacing before object operator

Each item on the list has the current measurements represented as graphs and a historical view about its previous usage. You can also view per-project statistics for a wide range of PHP related projects.

In this post to his site Marko Pavlovic talks about REST APIs, some of the non-CRUD (create, read, update, delete) operations that need to be performed and how the Command design pattern can help.

We’ve all been here: the data model has been designed, and we have the entities and relationships implemented. It is finally time to code up the business logic and we are faced with solving these problems: The actions we want to implement on a particular model are not part of the good old CRUD (Create, Read, Update, Delete) operations, and we need to make a lot of non-standard controller actions, and routes. [Also] the actions we want to implement do not belong to a any model, and we have to create a new controller just for the "API".

He gives a more concrete example to illustrate the problem using "sites", "visits" and a desire to add analytics functionality using each's data. He points out two common actions taken when something like this comes up: either new methods on the pre-existing controllers or possibly making a new controller to handle it. Instead he suggests using the Command pattern to handle requests themselves as self-contained items. This gathers all the logic needed in to one place and the Report instance can then be used as-is by the response that needs to render the results.

Derick Rethans has continued his series looking at the code coverage handling that XDebug and PHPUnit make available, allowing you to find the spots in your code not tested much easier. In this new post he talks about a new feature coming to the XDebug tool - branch and path coverage.

Picking up from where we left last time, in this second article we will look at some upcoming functionality in Xdebug. Sebastian has been pressuring me for years to add branch and path coverage to Xdebug, with issue #1034. In the post I will show you what "branch and path coverage" is, and how it helps.

How does this new type of coverage differ from the current functionality? Derick goes on to explain the difference via a simple example (and its resulting coverage). In the first example, using the XDebug available today, shows a fully tested function despite not all paths being testing correctly (a false coverage report). He gets into the "under the covers" changes he's made including how the opcodes are reported and changes he's made to the VLD to make it handle the branching smarter and make coverage more than just a "lines covered" metric. He shows an updated graph of the new coverage/branch flow and what a resulting coverage report might look like with the new "Paths" reporting.

The SitePoint PHP blog has posted the latest part in their Jenkins+PHP series today. In this new article (the final part in the series) they use the Jenkins setup they've walked you through already and actually run the analysis on the PHP project and the resulting information.

The results of Jenkins come from different tools and will be placed in different locations within the Jenkins GUI. [...] Within this article, we will be going through each tool and have a look at what it reports back to us. In the end, we will also look at some extra details Jenkins collects for us. Since we build the same project several times, we will get straight lines within our graphs. In a real project, the graph would fluctuate.

He goes through some examples of the results from his analysis including screenshots and explanations for:

• PHP_CodeSniffer
• PHP MD (Mess Detector)
• PHP CPD (Copy & Paste Detector)
• PHP Depend
• PHPLOC (Lines Of Code)
• PHPUnit
• PHPDox

He also briefly mentions the "changes" information, showing you what changed in that particular build to help narrow down any issues that might have come up.

The Dutch Web Alliance has posted the fifth part (of seven) of their series looking at configuring the PHPStorm IDE to remotely debug and run your unit tests. In this article they focus in on getting coverage information from the tests and generating the reports.

They walk you through all of the terminology and configuration you'll need to get things working. They include an example of a Closer coverage configuration file (XML) to push the results out where PHPStorm can grab them. They show show the result (screenshot) of the coverage results being shown inside the IDE.

This is part five of the series, so if you'd like to get caught up check out the full table of contents for links to all of the posts so far.

WebDeveloperJuice.com has posted a list of several PHP tools that you can use to create Microsfot Excel reports from your data (some a bit more feature-packed than others).

Every time somebody does something unique with PHP that is far beyond the standards and norms of PHP applications. One must say you will truly be overwhelmed by the capabilities and features of PHP language. Microsoft Excel is widely used by most of the companies as a report generation tool and data analysis tool. [...] In this post we will have a look at the various Libraries that the PHP developers can use for generating Excel Reports in any PHP Application and for exporting the data to Microsoft Excel Spreadsheets.

The tools that made their list are:

• PHP Export Data
• PHP Excel Library
• Excel Writer (XML) PHP Library
• Php-Excel
• Pear Excel Writer Library

The Codeception testing tool has released a new major update with some interesting new features - the expected feature for generating code coverage reports (similar to other tools) but there's also the idea of "remote code coverage" introduced.

There is no magic in local codecoverage. XDebug and PHP_CodeCoverage libraries do their job. The tricky thing is remote codecoverage. We attach small script into application's front controller. When a special header is sent this script starts to collect coverage information. And in the end of tests, this data is merged, serialized and sent back to Codeception. So you can test and collect coverage report even on staging servers in real environment.

They also mention a few other updates in the release - new Redis and MongoDb modules, UX improvements and the normal bugfixes. You can find out more about the code coverage feature in their manual or just about the project in general from the main site.