The ReactPHP website displays a PHP notice with its stack trace in the activity box on the lower right (see attached screenshot).

This happens because the $participation array does not contain the index all. Might have sth. to do with connectivity issues to Travis, or maybe they changed something on their side?

The README contains information on how to build this project to a set of static files. Once these files have been generated, you can either view them locally or deploy them to a website.

This project uses Travis to deploy these resulting files to https://github.com/reactphp/reactphp.github.io. That other project is set up to use GitHub pages to simply publish everything that is stored within to the web under reactphp.github.io which uses the alias reactphp.org.

This deployment is configured as part of this project via the .travis.yml file. This means that whenever Travis detects changes on the master branch of this repository, a new rebuild and deployment will be triggered instantly.

However, this project builds the website from a number of external repositories, in particular the READMEs of our components. This means that most of the changes that are supposed to be published are actually not part of this project at all.

For this reason, this project uses Travis' cron jobs to trigger a website rebuild and deployment every day (https://travis-ci.org/reactphp/website/settings). This means that any changes will be picked up automatically once every day and the website will automatically stay up to date.

However, there are number of occasions where this "rebuild once per day" may not be sufficient. In particular, if a new component version is tagged and released, it may take up to 24h for this to show up on our homepage. This means that if the release is announced, the website may still show an outdated version.

For this reason, this ticket adds required documentation on how to manually trigger a new website rebuild and deployment to instantly update the website. Go to https://travis-ci.org/reactphp/website and click on "Trigger build" in the upper right corner (hamburger menu). This should open a "Trigger a custom build (Beta Feature)" dialog that can simply be confirmed with the preset values. Obviously, this requires valid authentication. This should lead you to a new build which should take a minute or two to complete and publish online 🎉

Opening this ticket for the reference only (https://github.com/reactphp/react/wiki/ReleaseProcess#release-checklist), so I'll assume this can be closed right away.

One of the criticisms made against reactphp is the lack of documentation. Currently the website shows a small example on making a webserver while there is a lot more to the project. My suggestion is to add project pages for each component on the website and add simple getting started examples. This to make the learning curve easier.

Mostly after releasing a new version for one of our ReactPHP components, we need to trigger the website build in order to show each new released version there. When running the GitHub actions deployment workflow for this, we recently tend to run into rate limitings:

Temporary error, will retry in 60s: API rate limit exceeded for installation ID 14316185.
PHP Fatal error:  Uncaught Github\Exception\RuntimeException: API rate limit exceeded for installation ID 14316185. in /home/runner/work/website/website/vendor/knplabs/github-api/lib/Github/HttpClient/Plugin/GithubExceptionThrower.php:126
Stack trace:
#0 /home/runner/work/website/website/vendor/php-http/httplug/src/Promise/HttpFulfilledPromise.php(34): Github\HttpClient\Plugin\GithubExceptionThrower->Github\HttpClient\Plugin\{closure}(Object(GuzzleHttp\Psr7\Response))
#1 /home/runner/work/website/website/vendor/knplabs/github-api/lib/Github/HttpClient/Plugin/GithubExceptionThrower.php(127): Http\Client\Promise\HttpFulfilledPromise->then(Object(Closure))
#2 /home/runner/work/website/website/vendor/php-http/client-common/src/Plugin/VersionBridgePlugin.php(19): Github\HttpClient\Plugin\GithubExceptionThrower->doHandleRequest(Object(GuzzleHttp\Psr7\Request), Object(Closure), Object(Closure))
#3 /home/runner/work/website/website/vendor/php-http/client-common/src/PluginClient.php(161): Github\HttpClient\Plugin\GithubExceptionThrower in /home/runner/work/website/website/vendor/knplabs/github-api/lib/Github/HttpClient/Plugin/GithubExceptionThrower.php on line 126
Error: Process completed with exit code 255.

It sometimes works when retrying to run the failed workflow, but with each release it seems to get harder for this deployment process to be successful. I didn't investigate this in detail yet, so I'm happy about your input on this.

For some reason, the website build process detects reactphp/datagram v1.8.0 as the latest version and and does not include the latest release: https://github.com/reactphp/datagram/releases/tag/v1.9.0

I've manually executed the build again, but the problem persists. See also last build output: https://github.com/reactphp/website/actions/runs/4151388784/jobs/7181669476#step:8:120

Only stumbled upon this today and haven't analyzed this in-depth yet, any help would be appreciated.

With the new website design, i also introduced a new logo. @clue suggested we should discuss this in a separate issue, so here it is.

The R stands obviously for React, the red line is both a P (for PHP) and a symbol for the loop.

/ping @WyriHaximus @cboden @clue

We received a tweet yesterday about the inability to reach the website via HTTPS: https://twitter.com/_le_futuriste/status/898835476827828224

We can handle this in a few different ways:

• Do nothing and wait for @github to support it
• Set up an AWS CloudFront distribution
• Set up CloudFlare

The latter is by far my favourite but I don't mind setting up the CloudFront distribution and paying for it 😄 .

The navigation menu is acting weird on Safari:

• Touching the menu produces the above screenshot
• Upon scrolling down it appears
• Once open the X to close only works if the user has scrolled back to the top of the page
• Closing the menu produces the same screenshot posted above

We should add some Atom feed links to the releases page. These feeds are already created by GitHub, so we don't really need to have them as part of our website and it's merely a matter of setting up some links.

<link href="https://github.com/reactphp/socket/releases.atom" type="application/atom+xml" rel="alternate" title="Socket releases" />

Also related to #30 at which point we may want to dump the same listing into an Atom feed.

The homepage currently links to https://github.com/reactphp as the main entry point for GitHub links. Now that reactphp/reactphp#384 is in, I think it makes more sense to link to https://github.com/reactphp/react instead. After discussing this with a number of people I agree that linking to the organization level may leave people wondering where to look next. Note that we may have to address reactphp/reactphp#348 first.

Any input is welcome 👍

The example in the home page is outdated. By using it as is we get a fatal error.

index.php:

require 'vendor/autoload.php';

$app = function ($request, $response) {
    $response->writeHead(200, array('Content-Type' => 'text/plain'));
    $response->end("Hello World\n");
};

$loop = React\EventLoop\Factory::create();
$socket = new React\Socket\Server($loop);
$http = new React\Http\Server($socket, $loop);

$http->on('request', $app);
echo "Server running at http://127.0.0.1:1337\n";

$socket->listen(1337);
$loop->run();

composer.json:

{
    "require": {
        "react/event-loop": "^0.4.3",
        "react/socket": "^0.8",
        "react/http": "^0.7.1"
    }
}

error message:

PHP Fatal error:  Uncaught ArgumentCountError: Too few arguments to function React\Socket\Server::__construct(), 1 passed in reactphp\index.php on line 11 and at least 2 expected in reactphp\vendor\react\socket\src\Server.php:12
Stack trace:
#0 reactphp\index.php(11): React\Socket\Server->__construct(Object(React\EventLoop\StreamSelectLoop))
#1 {main}
  thrown in reactphp\vendor\react\socket\src\Server.php on line 12

Fatal error: Uncaught ArgumentCountError: Too few arguments to function React\Socket\Server::__construct(), 1 passed in reactphp\index.php on line 11 and at least 2 expected in reactphp\vendor\react\socket\src\Server.php:12
Stack trace:
#0 reactphp\index.php(11): React\Socket\Server->__construct(Object(React\EventLoop\StreamSelectLoop))
#1 {main}
  thrown in reactphp\vendor\react\socket\src\Server.php on line 12

The changelog for each component does not currently link to issues (#NUMBER) or author names (@NAME). Compare for example https://reactphp.org/stream/changelog.html with https://github.com/reactphp/stream/releases.

I think it makes sense to implement this feature so that links are added automatically for consistency reasons. This only applies to the changelog and not the other markdown files, so I suppose it's relatively safe to apply some simple regular expressions here.

Any input is welcome 👍

The README contains information on how to build this project to a set of static files. Once these files have been generated, you can either view them locally or deploy them to a website.

This project uses Travis to deploy these resulting files to https://github.com/reactphp/reactphp.github.io. That other project is set up to use GitHub pages to simply publish everything that is stored within to the web under reactphp.github.io which uses the alias reactphp.org.

This deployment is configured as part of this project via the .travis.yml file. This means that whenever Travis detects changes on the master branch of this repository, a new rebuild and deployment will be triggered instantly.

However, this project builds the website from a number of external repositories, in particular the READMEs of our components. This means that most of the changes that are supposed to be published are actually not part of this project at all.

For this reason, this project uses Travis' cron jobs to trigger a website rebuild and deployment every day (https://travis-ci.org/reactphp/website/settings). This means that any changes will be picked up automatically once every day and the website will automatically stay up to date.

However, there are number of occasions where this "rebuild once per day" may not be sufficient. In particular, if a new component version is tagged and released, it may take up to 24h for this to show up on our homepage. This means that if the release is announced, the website may still show an outdated version.
– See #24

This release process currently needs to be triggered manually as per https://github.com/reactphp/react/wiki/ReleaseProcess#release-checklist or it may take up to 24h before release updates show up automatically.

To improve this, we should automatically trigger a website rebuild whenever a new component release is tagged. The easiest way would be to set up a webhook for each component to trigger a simple script which will then trigger the Travis CI API (https://docs.travis-ci.com/user/triggering-builds/). In this case, we can probably also remove the cron job.

Implementation wise this isn't too hard and should really only be a simple PHP script with 10 lines or so. Question remains on where to best store this script (like my personal website hosting?) and/or whether there are any better alternatives? Any input is appreciated!

Currently, the website shows a changelog for each individual component, for example https://reactphp.org/socket/changelog.html. I think we agree that this makes perfect sense, for example for users wishing to upgrade a single component.

Additionally, we should also add a changelog for all components listing all the changes on one page. This allows users to have a quick glimpse at "what changed since last time I've upgraded?", "what changed in the last 6 months?", "how active is this project?".

We can use GitHub's releases API to get a list of all releases for a single repository and use GitHub's organization API to iterate over all repositories within the @reactphp organization. An example output of this could look something like this: https://gist.github.com/clue/f2be153e5ac73773dc75df2131eacd04 (created via https://gist.github.com/clue/431368a31405b76ab5cc643c7b00ad37)

For now, dumping this into a single HTML file on the website should suffice, in the future we may want to apply some pagination logic (possibly by year or number of entries).

GitHub started supporting HTTPS for custom domains a few days ago. We currently rely on Cloudflare (#18) as an intermediary to offer HTTPS. While Cloudflare has worked really well, we may as well switch back now that GitHub has native HTTPS support, so that we rely on one less external provider.

Changing this is simply a matter of updating the DNS A records as per this article: https://help.github.com/articles/setting-up-an-apex-domain/#configuring-a-records-with-your-dns-provider