On a SessionStore object, there was already a remove() function, but this function only allowed for removing a child of the session store.

For instances where a SessionStore has been passed to a class for encapsulated session usage, it would be useful for that class to be able to remove the SessionStore itself. This could be done like this:

$encapsulatedSession = $session->get("example.auth");
$authentication = new Auth($encapsulatedSession);

// Inside Auth:

function logout() {
    $this->encapsulatedSession->remove();
}

Note that the above example calls remove() with no parameters, indicating that we want to remove the store itself (and all children).

Along with some working example code in /example, the main feature added to this development release is the ability to resolve JSON responses, as with the client-side fetch API.

This means that if you are expecting a response to be a JSON document, returning $response->json() will resolve a promise that will receive the pre-decoded JSON object for use.

Check out example/02-post-request.php for example code showcasing this.

While using this library in real world tests, it seems that a lot of APIs (Github’s for example) require a useragent header to be sent with a request.

It’s possible to set your own headers, but this shouldn’t be a required step, as just using curl on the commandline or from PHP automatically sets their default useragent, so now this library does too.

With this release, the name, description and lists of required/optional parameters are provided to Commands by implementing abstract functions.

There are two main reasons that this has been changed:

1. It is impossible to forget to implement the required parts of a Command now.
2. This allows the Commands’ constructors to be used to have data injected from outside of the application, without interference from the setup of command parameters, etc.

The reason this repository has been waiting at v0.8 for quite a while is because the idea of returning Entity objects that extend Rows was being worked on. It would be so useful to perform a fetch and receive the actual object you want to work with, rather than a plain Row object.

However, as explained in #139 , the Repository design pattern can be used to achieve this with very readable code, and without requiring any more changes to this repository itself.

That means that there are no outstanding bugs to fix or features to implement in order to perform a stable release of Database!

Have fun and keep your eye on php.gt/sqlbuilder for database templating coming your way.

Even though there are only two blueprints so far, the functionality to create a project from a given blueprint has been added to this release.

Usage:

gt create project-name --blueprint blueprint-name

To utilise this project as a standalone dependency, the script will be called as a dependency of the main Composer project on the development system. This release improves the loading of the Composer autoloader, allowing it to be used standalone or as a dependency.

The PHP.Gt Installer is a script intended to be installed globally using composer global require phpgt/installer. It makes the gt command available to your command line, in order to perform simple tasks like creating a new PHP.Gt WebEngine application.

In the v1 release, there are only two pieces of functionality:

1. To call composer create-project to create new WebEngine applications from Blueprints.
2. To pass through the gt-* commands available within WebEngine applications.

In total, the functionality at v1 is as follows:

$ gt
PHP.Gt Installer

Available commands:
 • create       Create a new WebEngine application
 • serve        Run a local HTTP server
 • build        Build the client-side files
 • run          Start a local server, cron and build runner
 • help         Display information about available commands

Users can pass arbitrary arguments to commands which are accessible in the ArgumentValueList to the developer (#16).

The argument value list getter can provide a default value if the user has not provided one.

The ServerRequest object has the most functionality as it represents the main object in use in a server-side Http library. This release marks the commit where the ServerRequest object has reached 100% test coverage. There have been many tweaks to achieve this along the way, and a few bugs found too.

Still to test are three objects: Message, Stream and UriResolver.

The Request and Response objects are arguably the most important in this repository. They contain references to many other objects within the repository and in the process of fully unit testing them, have reached 100% coverage on the Header, Uri and ParameterType objects.

This release consists mainly of unit tests. The intention is to get the codebase to 100% test coverage before the v3 WebEngine release is considered stable.

There are no new features planned to be implemented in this repository before v1 release, but the process of chasing 100% coverage always finds missing functionality or bugs.

This minor update tidies up the way that the default commands are handled with no arguments (for example, a common usage where a user calls the application with no commands or arguments).

The default command is now always “help” and will always display the list of available commands.

The repository has been in use for many months now, but has not made a v1 release until now because of a tricky bug that only occurred every so often in the unit tests.

The bug was caused by using in_array without the strict type flag. This was only a bug in the unit tests, so no new functionality has been added or changed to mark the stable release.

All functionality that was tagged to make its way into v1 release has been implemented and fully tested, so here it is, v1.0.0 of the Command Line Interface builder!

The main reason for the timing of this release is to allow php.gt/installer to also be released as stable, as the Installer is the next in the critical path of repositories that require stable release to get the whole of WebEngine v3 stable.

Have fun!

The final backwards-breaking change is that the path of a cookie is now always hard-coded to “/” - as setting a cookie per-directory is not recommended behaviour and can lead to confusing side effects.

There are a few integration tests to be made on this simple repository before it is released as v1.0.0, but until then there will be no backwards-breaking changes introduced.

Simple as it is, the Stream object has been fully tested to ensure that in/out/err are identified correctly and the correct exceptions are thrown when necessary.

Bugs were found; bugs were fixed. Moving on to the other Command subclasses.

Thorough testing is uncovering plenty of small bugs and improvements. No new features implemented in this pre-release, but check the diff to see the tests and changes to the Command class.

The explorative coding phase is complete and the library is beginning to take shape. In this prerelease, adjusting the code as unit test coverage increases, a backwards breaking change is introduced: the Command object now holds the write and writeLine functions.

More tests are added in this release as the repository gets closer to stable release. As this is getting closer, the minimum-stability composer flag has been removed, meaning it no longer depends on dev releases.

This pre-release changes the API of many functions, allowing more parameters to be nullable, using default values where appropriate.

Streams have been renamed throughout to output, as the class represents multiple streams.

Static functions can now be called from the crontab file. Further tests have been written to ensure missing functions and scripts will be handled correctly.

The final part of the functionality is in the testing phase. Commands that are listed within the crontab file are executed. This behaves exactly the same as the unix crontab, apart from the shell used is the current system shell, running as the calling user.