opdavies/drupalcampbristol
Archived
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Update core 8.3.0

Browse source
This commit is contained in:
Rob Davies 2017-04-13 15:53:35 +01:00
parent da7a7918f8
commit cd7a898e66
6144 changed files with 132297 additions and 87747 deletions
Download patch file Download diff file Expand all files Collapse all files

23
web/vendor/zendframework/zend-feed/doc/book/consuming-atom-entry.md vendored Normal file
View file

@ -0,0 +1,23 @@
# Consuming a Single Atom Entry
Single Atom `<entry>` elements are also valid by themselves. Usually the URL for
an entry is the feed's URL followed by `/<entryId>`, such as
`http://atom.example.com/feed/1`, using the example URL we used above. This
pattern may exist for some web services which use Atom as a container syntax.
If you read a single entry, you will have a `Zend\Feed\Reader\Entry\Atom` object.
## Reading a Single-Entry Atom Feed
```php
$entry = Zend\Feed\Reader\Reader::import('http://atom.example.com/feed/1');
echo 'Entry title: ' . $entry->getTitle();
```
> ## Importing requires an HTTP client
>
> To import a feed, you will need to have an [HTTP client](zend.feed.http-clients)
> available.
>
> If you are not using zend-http, you will need to inject `Reader` with the HTTP
> client. See the [section on providing a client to Reader](http-clients.md#providing-a-client-to-reader).

62
web/vendor/zendframework/zend-feed/doc/book/consuming-atom.md vendored Normal file
View file

@ -0,0 +1,62 @@
# Consuming Atom Feeds
`Zend\Feed\Reader\Feed\Atom` is used in much the same way as
`Zend\Feed\Reader\Feed\Rss`. It provides the same access to feed-level
properties and iteration over entries in the feed. The main difference is in the
structure of the Atom protocol itself. Atom is a successor to RSS; it is a
more generalized protocol and it is designed to deal more easily with feeds that
provide their full content inside the feed, splitting RSS' `description` tag
into two elements, `summary` and `content`, for that purpose.
## Basic Use of an Atom Feed
Read an Atom feed and print the `title` and `summary` of each entry:
```php
$feed = Zend\Feed\Reader\Reader::import('http://atom.example.com/feed/');
echo 'The feed contains ' . $feed->count() . ' entries.' . "\n\n";
foreach ($feed as $entry) {
echo 'Title: ' . $entry->getTitle() . "\n";
echo 'Description: ' . $entry->getDescription() . "\n";
echo 'URL: ' . $entry->getLink() . "\n\n";
}
```
> ## Importing requires an HTTP client
>
> To import a feed, you will need to have an [HTTP client](zend.feed.http-clients)
> available.
>
> If you are not using zend-http, you will need to inject `Reader` with the HTTP
> client. See the [section on providing a client to Reader](http-clients.md#providing-a-client-to-reader).
In an Atom feed, you can expect to find the following feed properties:
- `title`: The feed's title, same as RSS' channel title.
- `id`: Every feed and entry in Atom has a unique identifier.
- `link`: Feeds can have multiple links, which are distinguished by a `type`
attribute. The equivalent to RSS's channel link would be `type="text/html"`.
If the link is to an alternate version of the same content that's in the feed,
it would have a `rel="alternate"` attribute.
- `subtitle`: The feed's description, equivalent to RSS' channel description.
- `author`: The feed's author, with `name` and `email` sub-tags.
Atom entries commonly have the following properties:
- `id`: The entry's unique identifier.
- `title`: The entry's title, same as RSS item titles.
- `link`: A link to another format or an alternate view of this entry.
The link property of an atom entry typically has an `href` attribute.
- `summary`: A summary of this entry's content.
- `content`: The full content of the entry; can be skipped if the feed just
contains summaries.
- `author`: with `name` and `email` sub-tags like feeds have.
- `published`: the date the entry was published, in RFC 3339 format.
- `updated`: the date the entry was last updated, in RFC 3339 format.
Where relevant, `Zend\Feed` supports a number of common RSS extensions including
Dublin Core; Content, Slash, Syndication, and Syndication/Thread; and several
others in common use on blogs.
For more information on Atom and plenty of resources, see
[http://www.atomenabled.org/](http://www.atomenabled.org/).

99
web/vendor/zendframework/zend-feed/doc/book/consuming-rss.md vendored Normal file
View file

@ -0,0 +1,99 @@
# Consuming RSS Feeds
## Reading a feed
To read an RSS feed, pass its URL to `Zend\Feed\Reader\Reader::import()`:
```php
$channel = Zend\Feed\Reader\Reader::import('http://rss.example.com/channelName');
```
> ## Importing requires an HTTP client
>
> To import a feed, you will need to have an [HTTP client](zend.feed.http-clients)
> available.
>
> If you are not using zend-http, you will need to inject `Reader` with the HTTP
> client. See the [section on providing a client to Reader](http-clients.md#providing-a-client-to-reader).
If any errors occur fetching the feed, a
`Zend\Feed\Reader\Exception\RuntimeException` will be thrown.
## Get properties
Once you have a feed object, you can access any of the standard RSS channel
properties via the various instance getter methods:
```php
echo $channel->getTitle();
echo $channel->getAuthor();
// etc.
```
If channel properties have attributes, the getter method will return a key/value
pair, where the key is the attribute name, and the value is the attribute value.
```php
$author = $channel->getAuthor();
echo $author['name'];
```
Most commonly, you'll want to loop through the feed and do something with its
entries. `Zend\Feed\Reader\Feed\Rss` internally converts all entries to a
`Zend\Feed\Reader\Entry\Rss` instance. Entry properties, similarly to channel
properties, can be accessed via getter methods, such as `getTitle`,
`getDescription`, etc.
An example of printing all titles of articles in a channel is:
```php
foreach ($channel as $item) {
echo $item->getTitle() . "\n";
}
```
If you are not familiar with RSS, here are the standard elements you can expect
to be available in an RSS channel and in individual RSS items (entries).
Required channel elements:
- `title`: The name of the channel.
- `link`: The URL of the web site corresponding to the channel.
- `description`: A sentence (or more) describing the channel.
Common optional channel elements:
- `pubDate`: The publication date of this set of content, in RFC 822 date
format.
- `language`: The language the channel is written in.
- `category`: One or more (specified by multiple tags) categories the channel
belongs to.
RSS `<item>` elements do not have any strictly required elements. However,
either `title` or `description` must be present.
Common item elements:
- `title`: The title of the item.
- `link`: The URL of the item.
- `description`: A synopsis of the item.
- `author`: The author's email address.
- `category`: One more categories that the item belongs to.
- `comments`: URL of comments relating to this item.
- `pubDate`: The date the item was published, in RFC 822 date format.
In your code you can always test to see if an element is non-empty by calling
the getter:
```php
if ($item->getPropname()) {
// ... proceed.
}
```
Where relevant, `Zend\Feed` supports a number of common RSS extensions including
Dublin Core, Atom (inside RSS); the Content, Slash, Syndication,
Syndication/Thread extensions; as well as several others.
Please see the official [RSS 2.0 specification](http://cyber.law.harvard.edu/rss/rss.html)
for further information.

48
web/vendor/zendframework/zend-feed/doc/book/find-feeds.md vendored Normal file
View file

@ -0,0 +1,48 @@
# Feed Discovery from Web Pages
Web pages often contain `<link>` tags that refer to feeds with content relevant
to the particular page. `Zend\Feed\Reader\Reader` enables you to retrieve all
feeds referenced by a web page with one method call:
```php
$feedLinks = Zend\Feed\Reader\Reader::findFeedLinks('http://www.example.com/news.html');
```
> ## Finding feed links requires an HTTP client
>
> To find feed links, you will need to have an [HTTP client](zend.feed.http-clients)
> available.
>
> If you are not using zend-http, you will need to inject `Reader` with the HTTP
> client. See the [section on providing a client to Reader](http-clients.md#providing-a-client-to-reader).
Here the `findFeedLinks()` method returns a `Zend\Feed\Reader\FeedSet` object,
which is in turn a collection of other `Zend\Feed\Reader\FeedSet` objects, each
referenced by `<link>` tags on the `news.html` web page.
`Zend\Feed\Reader\Reader` will throw a
`Zend\Feed\Reader\Exception\RuntimeException` upon failure, such as an HTTP
404 response code or a malformed feed.
You can examine all feed links located by iterating across the collection:
```php
$rssFeed = null;
$feedLinks = Zend\Feed\Reader\Reader::findFeedLinks('http://www.example.com/news.html');
foreach ($feedLinks as $link) {
if (stripos($link['type'], 'application/rss+xml') !== false) {
$rssFeed = $link['href'];
break;
}
```
Each `Zend\Feed\Reader\FeedSet` object will expose the `rel`, `href`, `type`,
and `title` properties of detected links for all RSS, Atom, or RDF feeds. You
can always select the first encountered link of each type by using a shortcut:
the first encountered link of a given type is assigned to a property named after
the feed type.
```php
$rssFeed = null;
$feedLinks = Zend\Feed\Reader\Reader::findFeedLinks('http://www.example.com/news.html');
$firstAtomFeed = $feedLinks->atom;
```

236
web/vendor/zendframework/zend-feed/doc/book/http-clients.md vendored Normal file
View file

@ -0,0 +1,236 @@
# HTTP Clients and zend-feed
Several operations in zend-feed's Reader subcomponent require an HTTP client:
- importing a feed
- finding links in a feed
In order to allow developers a choice in HTTP clients, the subcomponent defines
several interfaces and classes. Elsewhere in the documentation, we reference
where an HTTP client may be used; this document details what constitutes an HTTP
client and its behavior, and some of the concrete classes available within the
component for implementing this behavior.
## ClientInterface and HeaderAwareClientInterface
First, we define two interfaces for clients,
`Zend\Feed\Reader\Http\ClientInterface` and `HeaderAwareClientInterface`:
```php
namespace Zend\Feed\Reader\Http;
interface ClientInterface
{
/**
* Make a GET request to a given URL.
*
* @param string $url
* @return ResponseInterface
*/
public function get($url);
}
interface HeaderAwareClientInterface extends ClientInterface
{
/**
* Make a GET request to a given URL.
*
* @param string $url
* @param array $headers
* @return ResponseInterface
*/
public function get($url, array $headers = []);
}
```
The first is header-agnostic, and assumes that the client will simply perform an
HTTP GET request. The second allows providing headers to the client; typically,
these are used for HTTP caching headers. `$headers` must be in the following
structure:
```php
$headers = [
'X-Header-Name' => [
'header',
'values',
],
];
```
i.e., each key is a header name, and each value is an array of values for that
header. If the header represents only a single value, it should be an array with
that value:
```php
$headers = [
'Accept' => [ 'application/rss+xml' ],
];
```
A call to `get()` should yield a *response*.
## ResponseInterface and HeaderAwareResponseInterface
Responses are modeled using `Zend\Feed\Reader\Http\ResponseInterface` and
`HeaderAwareResponseInterface`:
```php
namespace Zend\Feed\Reader\Http;
class ResponseInterface
{
/**
* Retrieve the status code.
*
* @return int
*/
public function getStatusCode();
/**
* Retrieve the response body contents.
*
* @return string
*/
public function getBody();
}
class HeaderAwareResponseInterface extends ResponseInterface
{
/**
* Retrieve a named header line.
*
* Retrieve a header by name; all values MUST be concatenated to a single
* line. If no matching header is found, return the $default value.
*
* @param string $name
* @param null|string $default
* @return string
public function getHeaderLine($name, $default = null);
}
```
Internally, `Reader` will typehint against `ClientInterface` for the bulk of
operations. In some cases, however, certain capabilities are only possible if
the response can provide headers (e.g., for caching); in such cases, it will
check the instance against `HeaderAwareResponseInterface`, and only call
`getHeaderLine()` if it matches.
## Response
zend-feed ships with a generic `ResponseInterface` implementation,
`Zend\Feed\Http\Response`. It implements `HeaderAwareResponseInterface`, and
defines the following constructor:
```php
namespace Zend\Feed\Reader\Http;
class Response implements HeaderAwareResponseInterface
{
/**
* Constructor
*
* @param int $statusCode Response status code
* @param string $body Response body
* @param array $headers Response headers, if available
*/
public function __construct($statusCode, $body, array $headers = []);
}
```
## PSR-7 Response
[PSR-7](http://www.php-fig.org/psr/psr-7/) defines a set of HTTP message
interfaces, but not a client interface. To facilitate wrapping an HTTP client
that uses PSR-7 messages, we provide `Zend\Feed\Reader\Psr7ResponseDecorator`:
```php
namespace Zend\Feed\Reader\Http;
use Psr\Http\Message\ResponseInterface as PsrResponseInterface;
class Psr7ResponseDecorator implements HeaderAwareResponseInterface
{
/**
* @param PsrResponseInterface $response
*/
public function __construct(PsrResponseInterface $response);
/**
* @return PsrResponseInterface
*/
public function getDecoratedResponse();
}
```
Clients can then take the PSR-7 response they receive, pass it to the decorator,
and return the decorator.
To use the PSR-7 response, you will need to add the PSR-7 interfaces to your
application, if they are not already installed by the client of your choice:
```bash
$ composer require psr/http-message
```
## zend-http
We also provide a zend-http client decorator,
`Zend\Feed\Reader\Http\ZendHttpClientDecorator`:
```php
namespace Zend\Feed\Reader\Http;
use Zend\Http\Client as HttpClient;
class ZendHttpClientDecorator implements HeaderAwareClientInterface
{
/**
* @param HttpClient $client
*/
public function __construct(HttpClient $client);
/**
* @return HttpClient
*/
public function getDecoratedClient();
}
```
Its `get()` implementation returns a `Response` instance seeded from the
zend-http response returned, including status, body, and headers.
zend-http is the default implementation assumed by `Zend\Feed\Reader\Reader`,
but *is not installed by default*. You may install it using composer:
```bash
$ composer require zendframework/zend-http
```
## Providing a client to Reader
By default, `Zend\Feed\Reader\Reader` will lazy load a zend-http client. If you
have not installed zend-http, however, PHP will raise an error indicating the
class is not found!
As such, you have two options:
1. Install zend-http: `composer require zendframework/zend-http`.
2. Inject the `Reader` with your own HTTP client.
To accomplish the second, you will need an implementation of
`Zend\Feed\Reader\Http\ClientInterface` or `HeaderAwareClientInterface`, and an
instance of that implementation. Once you do, you can use the static method
`setHttpClient()` to inject it.
As an example, let's say you've created a PSR-7-based implementation named
`My\Http\Psr7FeedClient`. You could then do the following:
```php
use My\Http\Psr7FeedClient;
use Zend\Feed\Reader\Reader;
Reader::setHttpClient(new Psr7FeedClient());
```
Your client will then be used for all `import()` and `findFeedLinks()`
operations.

49
web/vendor/zendframework/zend-feed/doc/book/importing.md vendored Normal file
View file

@ -0,0 +1,49 @@
# Importing Feeds
`Zend\Feed` enables developers to retrieve feeds via `Zend\Feader\Reader`. If
you know the URI of a feed, use the `Zend\Feed\Reader\Reader::import()` method
to consume it:
```php
$feed = Zend\Feed\Reader\Reader::import('http://feeds.example.com/feedName');
```
> ## Importing requires an HTTP client
>
> To import a feed, you will need to have an [HTTP client](zend.feed.http-clients)
> available.
>
> If you are not using zend-http, you will need to inject `Reader` with the HTTP
> client. See the [section on providing a client to Reader](http-clients.md#providing-a-client-to-reader).
You can also use `Zend\Feed\Reader\Reader` to fetch the contents of a feed from
a file or the contents of a PHP string variable:
```php
// importing a feed from a text file
$feedFromFile = Zend\Feed\Reader\Reader::importFile('feed.xml');
// importing a feed from a PHP string variable
$feedFromPHP = Zend\Feed\Reader\Reader::importString($feedString);
```
In each of the examples above, an object of a class that extends
`Zend\Feed\Reader\Feed\AbstractFeed` is returned upon success, depending on the
type of the feed. If an RSS feed were retrieved via one of the import methods
above, then a `Zend\Feed\Reader\Feed\Rss` object would be returned. On the other
hand, if an Atom feed were imported, then a `Zend\Feed\Reader\Feed\Atom` object
is returned. The import methods will also throw a
`Zend\Feed\Exception\Reader\RuntimeException` object upon failure, such as an
unreadable or malformed feed.
## Dumping the contents of a feed
To dump the contents of a `Zend\Feed\Reader\Feed\AbstractFeed` instance, you may
use the `saveXml()` method.
```php
assert($feed instanceof Zend\Feed\Reader\Feed\AbstractFeed);
// dump the feed to standard output
print $feed->saveXml();
```

10
web/vendor/zendframework/zend-feed/doc/book/index.html vendored Normal file
View file

@ -0,0 +1,10 @@
<div class="container">
<div class="jumbotron">
<h1>zend-feed</h1>
<p>Consume and generate Atom and RSS feeds, and interact with Pubsubhubbub.</p>
<pre><code class="language-bash">$ composer require zendframework/zend-feed</code></pre>
</div>
</div>

1
web/vendor/zendframework/zend-feed/doc/book/index.md vendored Symbolic link
View file

@ -0,0 +1 @@
../../README.md

62
web/vendor/zendframework/zend-feed/doc/book/intro.md vendored Normal file
View file

@ -0,0 +1,62 @@
# Introduction
`Zend\Feed` provides functionality for consuming RSS and Atom feeds. It provides
a natural syntax for accessing elements of feeds, feed attributes, and entry
attributes. `Zend\Feed` also has extensive support for modifying feed and entry
structure with the same natural syntax, and turning the result back into XML.
In the future, this modification support could provide support for the Atom
Publishing Protocol.
`Zend\Feed` consists of `Zend\Feed\Reader` for reading RSS and Atom feeds,
`Zend\Feed\Writer` for writing RSS and Atom feeds, and `Zend\Feed\PubSubHubbub`
for working with Hub servers. Furthermore, both `Zend\Feed\Reader` and
`Zend\Feed\Writer` support extensions which allows for working with additional
data in feeds, not covered in the core API but used in conjunction with RSS and
Atom feeds.
In the example below, we demonstrate a simple use case of retrieving an RSS feed
and saving relevant portions of the feed data to a simple PHP array, which could
then be used for printing the data, storing to a database, etc.
> ## RSS optional properties
>
> Many *RSS* feeds have different channel and item properties available. The
> *RSS* specification provides for many optional properties, so be aware of this
> when writing code to work with *RSS* data. `Zend\Feed` supports all optional
> properties of the core *RSS* and *Atom* specifications.
## Reading RSS Feed Data
```php
// Fetch the latest Slashdot headlines
try {
$slashdotRss =
Zend\Feed\Reader\Reader::import('http://rss.slashdot.org/Slashdot/slashdot');
} catch (Zend\Feed\Reader\Exception\RuntimeException $e) {
// feed import failed
echo "Exception caught importing feed: {$e->getMessage()}\n";
exit;
}
// Initialize the channel/feed data array
$channel = [
'title' => $slashdotRss->getTitle(),
'link' => $slashdotRss->getLink(),
'description' => $slashdotRss->getDescription(),
'items' => [],
];
// Loop over each channel item/entry and store relevant data for each
foreach ($slashdotRss as $item) {
$channel['items'][] = [
'title' => $item->getTitle(),
'link' => $item->getLink(),
'description' => $item->getDescription(),
];
}
```
Your `$channel` array now contains the basic meta-information for the RSS
channel and all items that it contained. The process is identical for Atom
feeds since `Zend\Feed` provides a common feed API; i.e. all getters and
setters are the same regardless of feed format.

90
web/vendor/zendframework/zend-feed/doc/book/psr7-clients.md vendored Normal file
View file

@ -0,0 +1,90 @@
# Using PSR-7 Clients
As noted in the previous section, you can [substitute your own HTTP client by implementing the ClientInterface](http-clients.md#clientinterface-and-headerawareclientinterface).
In this section, we'll demonstrate doing so in order to use a client that is
[PSR-7](http://www.php-fig.org/psr/psr-7/)-capable.
## Responses
zend-feed provides a facility to assist with generating a
`Zend\Feed\Reader\Response` from a PSR-7 `ResponseInterface` via
`Zend\Feed\Reader\Http\Psr7ResponseDecorator`. As such, if you have a
PSR-7-capable client, you can pass the response to this decorator, and
immediately return it from your custom client:
```php
return new Psr7ResponseDecorator($psr7Response);
```
We'll do this with our PSR-7 client.
## Guzzle
[Guzzle](http://docs.guzzlephp.org/en/latest/) is arguably the most popular HTTP
client library for PHP, and fully supports PSR-7 since version 5. Let's install
it:
```bash
$ composer require guzzlehttp/guzzle
```
We'll use the `GuzzleHttp\Client` to make our requests to feeds.
## Creating a client
From here, we'll create our client. To do this, we'll create a class that:
- implements `Zend\Feed\Reader\Http\ClientInterface`
- accepts a `GuzzleHttp\ClientInterface` to its constructor
- uses the Guzzle client to make the request
- returns a zend-feed response decorating the actual PSR-7 response
The code looks like this:
```php
use GuzzleHttp\Client;
use GuzzleHttp\ClientInterface as GuzzleClientInterface;
use Zend\Feed\Reader\Http\ClientInterface as FeedReaderHttpClientInterface;
use Zend\Feed\Reader\Http\Psr7ResponseDecorator;
class GuzzleClient implements FeedReaderHttpClientInterface
{
/**
* @var GuzzleClientInterface
*/
private $client;
/**
* @param GuzzleClientInterface|null $client
*/
public function __construct(GuzzleClientInterface $client = null)
{
$this->client = $client ?: new Client();
}
/**
* {@inheritdoc}
*/
public function get($uri)
{
return new Psr7ResponseDecorator(
$this->client->request('GET', $uri)
);
}
}
```
## Using the client
In order to use our new client, we need to tell `Zend\Feed\Reader\Reader` about
it:
```php
Zend\Feed\Reader\Reader::setHttpClient(new GuzzleClient());
```
From this point forward, this custom client will be used to retrieve feeds.
## References
This chapter is based on [a blog post by Stefan Gehrig](https://www.teqneers.de/2016/05/zendfeedreader-guzzle-and-psr-7/).

452
web/vendor/zendframework/zend-feed/doc/book/pubsubhubbub.md vendored Normal file
View file

@ -0,0 +1,452 @@
# Zend\\Feed\\PubSubHubbub
`Zend\Feed\PubSubHubbub` is an implementation of the [PubSubHubbub Core 0.2/0.3
Specification (Working Draft)](http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.3.html).
It offers implementations of a Pubsubhubbub Publisher and Subscriber suited to
PHP applications.
## What is PubSubHubbub?
Pubsubhubbub is an open, simple, web-scale, pubsub protocol. A common use case
to enable blogs (Publishers) to "push" updates from their RSS or Atom feeds
(Topics) to end Subscribers. These Subscribers will have subscribed to the
blog's RSS or Atom feed via a Hub, a central server which is notified of any
updates by the Publisher, and which then distributes these updates to all
Subscribers. Any feed may advertise that it supports one or more Hubs using an
Atom namespaced link element with a rel attribute of "hub" (i.e., `rel="hub"`).
Pubsubhubbub has garnered attention because it is a pubsub protocol which is
easy to implement and which operates over HTTP. Its philosophy is to replace the
traditional model where blog feeds have been polled at regular intervals to
detect and retrieve updates. Depending on the frequency of polling, this can
take a lot of time to propagate updates to interested parties from planet
aggregators to desktop readers. With a pubsub system in place, updates are not
simply polled by Subscribers, they are pushed to Subscribers, eliminating any
delay. For this reason, Pubsubhubbub forms part of what has been dubbed the
real-time web.
The protocol does not exist in isolation. Pubsub systems have been around for a
while, such as the familiar Jabber Publish-Subscribe protocol,
[XEP-0060](http://www.xmpp.org/extensions/xep-0060.html), or the less well-known
[rssCloud](http://www.rssboard.org/rsscloud-interface) (described in 2001).
However, these have not achieved widespread adoption due to either their
complexity, poor timing, or lack of suitability for web applications. rssCloud,
which was recently revived as a response to the appearance of Pubsubhubbub, has
also seen its usage increase significantly, though it lacks a formal
specification and currently does not support Atom 1.0 feeds.
Perhaps surprisingly given its relative early age, Pubsubhubbub is already in
use including in Google Reader and Feedburner, and there are plugins available
for Wordpress blogs.
## Architecture
`Zend\Feed\PubSubHubbub` implements two sides of the Pubsubhubbub 0.2/0.3
Specification: a Publisher and a Subscriber. It does not currently implement a
Hub Server.
A Publisher is responsible for notifying all supported Hubs (many can be
supported to add redundancy to the system) of any updates to its feeds, whether
they be Atom or RSS based. This is achieved by pinging the supported Hub Servers
with the URL of the updated feed. In Pubsubhubbub terminology, any updatable
resource capable of being subscribed to is referred to as a Topic. Once a ping
is received, the Hub will request the updated feed, process it for updated
items, and forward all updates to all Subscribers subscribed to that feed.
A Subscriber is any party or application which subscribes to one or more Hubs to
receive updates from a Topic hosted by a Publisher. The Subscriber never
directly communicates with the Publisher since the Hub acts as an intermediary,
accepting subscriptions and sending updates to Subscribers. The Subscriber
therefore communicates only with the Hub, either to subscribe or unsubscribe to
Topics, or when it receives updates from the Hub. This communication design
("Fat Pings") effectively removes the possibility of a "Thundering Herd" issue.
(Thundering Herds occur in a pubsub system where the Hub merely informs
Subscribers that an update is available, prompting all Subscribers to
immediately retrieve the feed from the Publisher, giving rise to a traffic
spike.) In Pubsubhubbub, the Hub distributes the actual update in a "Fat Ping"
so the Publisher is not subjected to any traffic spike.
`Zend\Feed\PubSubHubbub` implements Pubsubhubbub Publishers and Subscribers with
the classes `Zend\Feed\PubSubHubbub\Publisher` and
`Zend\Feed\PubSubHubbub\Subscriber`. In addition, the Subscriber implementation
may handle any feed updates forwarded from a Hub by using
`Zend\Feed\PubSubHubbub\Subscriber\Callback`. These classes, their use cases,
and etheir APIs are covered in subsequent sections.
## Zend\\Feed\\PubSubHubbub\\Publisher
In Pubsubhubbub, the Publisher is the party publishing a live feed with content
updates. This may be a blog, an aggregator, or even a web service with a public
feed based API. In order for these updates to be pushed to Subscribers, the
Publisher must notify all of its supported Hubs that an update has occurred
using a simple HTTP POST request containing the URI of the updated Topic (i.e.,
the updated RSS or Atom feed). The Hub will confirm receipt of the notification,
fetch the updated feed, and forward any updates to any Subscribers who have
subscribed to that Hub for updates from the relevant feed.
By design, this means the Publisher has very little to do except send these Hub
pings whenever its feeds change. As a result, the Publisher implementation is
extremely simple to use and requires very little work to setup and use when
feeds are updated.
`Zend\Feed\PubSubHubbub\Publisher` implements a full Pubsubhubbub Publisher. Its
setup for use primarily requires that it is configured with the URI endpoint for
all Hubs to be notified of updates, and the URIs of all Topics to be included in
the notifications.
The following example shows a Publisher notifying a collection of Hubs about
updates to a pair of local RSS and Atom feeds. The class retains a collection of
errors which include the Hub URLs, so that notification can be attempted again
later and/or logged if any notifications happen to fail. Each resulting error
array also includes a "response" key containing the related HTTP response
object. In the event of any errors, it is strongly recommended to attempt the
operation for failed Hub Endpoints at least once more at a future time. This may
require the use of either a scheduled task for this purpose or a job queue,
though such extra steps are optional.
```php
use Zend\Feed\PubSubHubbub\Publisher;
$publisher = Publisher;
$publisher->addHubUrls([
'http://pubsubhubbub.appspot.com/',
'http://hubbub.example.com',
]);
$publisher->addUpdatedTopicUrls([
'http://www.example.net/rss',
'http://www.example.net/atom',
]);
$publisher->notifyAll();
if (! $publisher->isSuccess()) {
// check for errors
$errors = $publisher->getErrors();
$failedHubs = [];
foreach ($errors as $error) {
$failedHubs[] = $error['hubUrl'];
}
}
// reschedule notifications for the failed Hubs in $failedHubs
```
If you prefer having more concrete control over the Publisher, the methods
`addHubUrls()` and `addUpdatedTopicUrls()` pass each array value to the singular
`addHubUrl()` and `addUpdatedTopicUrl()` public methods. There are also matching
`removeUpdatedTopicUrl()` and `removeHubUrl()` methods.
You can also skip setting Hub URIs, and notify each in turn using the
`notifyHub()` method which accepts the URI of a Hub endpoint as its only
argument.
There are no other tasks to cover. The Publisher implementation is very simple
since most of the feed processing and distribution is handled by the selected
Hubs. It is, however, important to detect errors and reschedule notifications as
soon as possible (with a reasonable maximum number of retries) to ensure
notifications reach all Subscribers. In many cases, as a final alternative, Hubs
may frequently poll your feeds to offer some additional tolerance for failures
both in terms of their own temporary downtime or Publisher errors or downtime.
## Zend\\Feed\\PubSubHubbub\\Subscriber
In Pubsubhubbub, the Subscriber is the party who wishes to receive updates to
any Topic (RSS or Atom feed). They achieve this by subscribing to one or more of
the Hubs advertised by that Topic, usually as a set of one or more Atom 1.0
links with a rel attribute of "hub" (i.e., `rel="hub"`). The Hub from that point
forward will send an Atom or RSS feed containing all updates to that
Subscriber's callback URL when it receives an update notification from the
Publisher. In this way, the Subscriber need never actually visit the original
feed (though it's still recommended at some level to ensure updates are
retrieved if ever a Hub goes offline). All subscription requests must contain
the URI of the Topic being subscribed and a callback URL which the Hub will use
to confirm the subscription and to forward updates.
The Subscriber therefore has two roles. The first is to *create* and *manage*
subscriptions, including subscribing for new Topics with a Hub, unsubscribing
(if necessary), and periodically renewing subscriptions, since they may have an
expiry set by the Hub. This is handled by `Zend\Feed\PubSubHubbub\Subscriber`.
The second role is to *accept updates* sent by a Hub to the Subscriber's
callback URL, i.e. the URI the Subscriber has assigned to handle updates. The
callback URL also handles events where the Hub contacts the Subscriber to
confirm all subscriptions and unsubscriptions. This is handled by using an
instance of `Zend\Feed\PubSubHubbub\Subscriber\Callback` when the callback URL
is accessed.
> ### Query strings in callback URLs
>
> `Zend\Feed\PubSubHubbub\Subscriber` implements the Pubsubhubbub 0.2/0.3
> specification. As this is a new specification version, not all Hubs currently
> implement it. The new specification allows the callback URL to include a query
> string which is used by this class, but not supported by all Hubs. In the
> interests of maximising compatibility, it is therefore recommended that the
> query string component of the Subscriber callback URI be presented as a path
> element, i.e. recognised as a parameter in the route associated with the
> callback URI and used by the application's router.
### Subscribing and Unsubscribing
`Zend\Feed\PubSubHubbub\Subscriber` implements a full Pubsubhubbub Subscriber
capable of subscribing to, or unsubscribing from, any Topic via any Hub
advertised by that Topic. It operates in conjunction with
`Zend\Feed\PubSubHubbub\Subscriber\Callback`, which accepts requests from a Hub
to confirm all subscription or unsubscription attempts (to prevent third-party
misuse).
Any subscription (or unsubscription) requires the relevant information before
proceeding, i.e. the URI of the Topic (Atom or RSS feed) to be subscribed to for
updates, and the URI of the endpoint for the Hub which will handle the
subscription and forwarding of the updates. The lifetime of a subscription may
be determined by the Hub, but most Hubs should support automatic subscription
refreshes by checking with the Subscriber. This is supported by
`Zend\Feed\PubSubHubbub\Subscriber\Callback` and requires no other work on your
part. It is still strongly recommended that you use the Hub-sourced subscription
time-to.live (ttl) to schedule the creation of new subscriptions (the process is
identical to that for any new subscription) to refresh it with the Hub. While it
should not be necessary per se, it covers cases where a Hub may not support
automatic subscription refreshing, and rules out Hub errors for additional
redundancy.
With the relevant information to hand, a subscription can be attempted as
demonstrated below:
```php
use Zend\Feed\PubSubHubbub\Model\Subscription;
use Zend\Feed\PubSubHubbub\Subscriber;
$storage = new Subscription;
$subscriber = new Subscriber;
$subscriber->setStorage($storage);
$subscriber->addHubUrl('http://hubbub.example.com');
$subscriber->setTopicUrl('http://www.example.net/rss.xml');
$subscriber->setCallbackUrl('http://www.mydomain.com/hubbub/callback');
$subscriber->subscribeAll();
```
In order to store subscriptions and offer access to this data for general use,
the component requires a database (a schema is provided later in this section).
By default, it is assumed the table name is "subscription", and it utilises
`Zend\Db\TableGateway\TableGateway` in the background, meaning it will use the
default adapter you have set for your application. You may also pass a specific
custom `Zend\Db\TableGateway\TableGateway` instance into the associated model
`Zend\Feed\PubSubHubbub\Model\Subscription`. This custom adapter may be as
simple in intent as changing the table name to use or as complex as you deem
necessary.
While this model is offered as a default ready-to-roll solution, you may create
your own model using any other backend or database layer (e.g. Doctrine) so long
as the resulting class implements the interface
`Zend\Feed\PubSubHubbub\Model\SubscriptionInterface`.
An example schema (MySQL) for a subscription table accessible by the provided
model may look similar to:
```sql
CREATE TABLE IF NOT EXISTS `subscription` (
`id` varchar(32) COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
`topic_url` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`hub_url` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`created_time` datetime DEFAULT NULL,
`lease_seconds` bigint(20) DEFAULT NULL,
`verify_token` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`secret` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`expiration_time` datetime DEFAULT NULL,
`subscription_state` varchar(12) COLLATE utf8_unicode_ci DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
```
Behind the scenes, the Subscriber above will send a request to the Hub endpoint
containing the following parameters (based on the previous example):
Parameter | Value | Explanation
--------- | ----- | -----------
`hub.callback` | `http://www.mydomain.com/hubbub/callback?xhub.subscription=5536df06b5dcb966edab3a4c4d56213c16a8184` | The URI used by a Hub to contact the Subscriber and either request confirmation of a (un)subscription request, or send updates from subscribed feeds. The appended query string contains a custom parameter (hence the xhub designation). It is a query string parameter preserved by the Hub and re-sent with all Subscriber requests. Its purpose is to allow the Subscriber to identify and look up the subscription associated with any Hub request in a backend storage medium. This is a non-standard parameter used by this component in preference to encoding a subscription key in the URI path, which is difficult to enforce generically. Nevertheless, since not all Hubs support query string parameters, we still strongly recommend adding the subscription key as a path component in the form `http://www.mydomain.com/hubbub/callback/5536df06b5dcb966edab3a4c4d56213c16a8184`. This requires defining a route capable of parsing out the final value of the key, retrieving the value, and passing it to the Subscriber callback object. The value should be passed into the method `Zend\PubSubHubbub\Subscriber\Callback::setSubscriptionKey()`. A detailed example is offered later.
`hub.lease_seconds` | `2592000` | The number of seconds for which the Subscriber would like a new subscription to remain valid (i.e. a TTL). Hubs may enforce their own maximum subscription period. All subscriptions should be renewed by re-subscribing before the subscription period ends to ensure continuity of updates. Hubs should additionally attempt to automatically refresh subscriptions before they expire by contacting Subscribers (handled automatically by the `Callback` class).
`hub.mode` | `subscribe` | Value indicating this is a subscription request. Unsubscription requests would use the "unsubscribe" value.
`hub.topic` | `http://www.example.net/rss.xml` | The URI of the Topic (i.e. Atom or RSS feed) which the Subscriber wishes to subscribe to for updates.
`hub.verify` | `sync` or `async` | Indicates to the Hub the preferred mode of verifying subscriptions or unsubscriptions. It is repeated twice in order of preference. Technically this component does not distinguish between the two modes and treats both equally.
`hub.verify_token` | `3065919804abcaa7212ae89.879827871253878386` | A verification token returned to the Subscriber by the Hub when it is confirming a subscription or unsubscription. Offers a measure of reliance that the confirmation request originates from the correct Hub to prevent misuse.
You can modify several of these parameters to indicate a different preference.
For example, you can set a different lease seconds value using
`Zend\Feed\PubSubHubbub\Subscriber::setLeaseSeconds(),` or show a preference for
the `async` verify mode by using `setPreferredVerificationMode(Zend\Feed\PubSubHubbub\PubSubHubbub::VERIFICATION_MODE_ASYNC)`.
However, the Hubs retain the capability to enforce their own preferences, and
for this reason the component is deliberately designed to work across almost any
set of options with minimum end-user configuration required. Conventions are
great when they work!
> ### Verification modes
>
> While Hubs may require the use of a specific verification mode (both are
> supported by `Zend\Feed\PubSubHubbub`), you may indicate a specific preference
> using the `setPreferredVerificationMode()` method. In `sync` (synchronous)
> mode, the Hub attempts to confirm a subscription as soon as it is received,
> and before responding to the subscription request. In `async` (asynchronous)
> mode, the Hub will return a response to the subscription request immediately,
> and its verification request may occur at a later time. Since
> `Zend\Feed\PubSubHubbub` implements the Subscriber verification role as a
> separate callback class and requires the use of a backend storage medium, it
> actually supports both transparently. In terms of end-user performance,
> asynchronous verification is very much preferred to eliminate the impact of a
> poorly performing Hub tying up end-user server resources and connections for
> too long.
Unsubscribing from a Topic follows the exact same pattern as the previous
example, with the exception that we should call `unsubscribeAll()` instead. The
parameters included are identical to a subscription request with the exception
that `hub.mode` is set to "unsubscribe".
By default, a new instance of `Zend\PubSubHubbub\Subscriber` will attempt to use
a database backed storage medium which defaults to using the default zend-db
adapter with a table name of "subscription". It is recommended to set a custom
storage solution where these defaults are not apt either by passing in a new
model supporting the required interface or by passing a new instance of
`Zend\Db\TableGateway\TableGateway` to the default model's constructor to change
the used table name.
### Handling Subscriber Callbacks
Whenever a subscription or unsubscription request is made, the Hub must verify
the request by forwarding a new verification request to the callback URL set in
the subscription or unsubscription parameters. To handle these Hub requests,
which will include all future communications containing Topic (feed) updates,
the callback URL should trigger the execution of an instance of
`Zend\Feed\PubSubHubbub\Subscriber\Callback` to handle the request.
The `Callback` class should be configured to use the same storage medium as the
`Subscriber` class. The bulk of the work is handled internal to these classes.
```php
use Zend\Feed\PubSubHubbub\Model\Subscription;
use Zend\Feed\PubSubHubbub\Subscriber\Callback;
$storage = new Subscription();
$callback = new Callback();
$callback->setStorage($storage);
$callback->handle();
$callback->sendResponse();
/*
* Check if the callback resulting in the receipt of a feed update.
* Otherwise it was either a (un)sub verification request or invalid request.
* Typically we need do nothing other than add feed update handling; the rest
* is handled internally by the class.
*/
if ($callback->hasFeedUpdate()) {
$feedString = $callback->getFeedUpdate();
/*
* Process the feed update asynchronously to avoid a Hub timeout.
*/
}
```
> #### Query and body parameters
>
> It should be noted that `Zend\Feed\PubSubHubbub\Subscriber\Callback` may
> independently parse any incoming query string and other parameters. This is
> necessary since PHP alters the structure and keys of a query string when it is
> parsed into the `$_GET` or `$_POST` superglobals; for example, all duplicate
> keys are ignored and periods are converted to underscores. Pubsubhubbub
> features both of these in the query strings it generates.
> #### Always delay feed processing
>
> It is essential that developers recognise that Hubs are only concerned with
> sending requests and receiving a response which verifies its receipt. If a
> feed update is received, it should never be processed on the spot since this
> leaves the Hub waiting for a response. Rather, any processing should be
> offloaded to another process or deferred until after a response has been
> returned to the Hub. One symptom of a failure to promptly complete Hub
> requests is that a Hub may continue to attempt delivery of the update or
> verification request leading to duplicated update attempts being processed by
> the Subscriber. This appears problematic, but in reality a Hub may apply a
> timeout of just a few seconds, and if no response is received within that time
> it may disconnect (assuming a delivery failure) and retry later. Note that
> Hubs are expected to distribute vast volumes of updates so their resources are
> stretched; please process feeds asynchronously (e.g. in a separate process or
> a job queue or even a cronjob) as much as possible.
### Setting Up And Using A Callback URL Route
As noted earlier, the `Zend\Feed\PubSubHubbub\Subscriber\Callback` class
receives the combined key associated with any subscription from the Hub via one
of two methods. The technically preferred method is to add this key to the
callback URL employed by the Hub in all future requests using a query string
parameter with the key `xhub.subscription`. However, for historical reasons
(primarily that this was not supported in Pubsubhubbub 0.1, and a late addition
to 0.2 ), it is strongly recommended to use the most compatible means of adding
this key to the callback URL by appending it to the URL's path.
Thus the URL `http://www.example.com/callback?xhub.subscription=key` would become
`http://www.example.com/callback/key`.
Since the query string method is the default in anticipation of a greater level
of future support for the full 0.2/0.3 specification, this requires some
additional work to implement.
The first step is to make the `Zend\Feed\PubSubHubbub\Subscriber\Callback` class
aware of the path contained subscription key. It's manually injected; therefore
it also requires manually defining a route for this purpose. This is achieved by
called the method `Zend\Feed\PubSubHubbub\Subscriber\Callback::setSubscriptionKey()`
with the parameter being the key value available from the router. The example
below demonstrates this using a zend-mvc controller.
```php
use Zend\Feed\PubSubHubbub\Model\Subscription;
use Zend\Feed\PubSubHubbub\Subscriber\Callback;
use Zend\Mvc\Controller\AbstractActionController;
class CallbackController extends AbstractActionController
{
public function indexAction()
{
$storage = new Subscription();
$callback = new Callback();
$callback->setStorage($storage);
/*
* Inject subscription key parsing from URL path using
* a parameter from the router.
*/
$subscriptionKey = $this->params()->fromRoute('subkey');
$callback->setSubscriptionKey($subscriptionKey);
$callback->handle();
$callback->sendResponse();
/*
* Check if the callback resulting in the receipt of a feed update.
* Otherwise it was either a (un)sub verification request or invalid
* request. Typically we need do nothing other than add feed update
* handling; the rest is handled internally by the class.
*/
if ($callback->hasFeedUpdate()) {
$feedString = $callback->getFeedUpdate();
/*
* Process the feed update asynchronously to avoid a Hub timeout.
*/
}
}
}
```
The example below illustrates adding a route mapping the path segment to a route
parameter, using zend-mvc:
```php
use Zend\Mvc\Router\Http\Segment as SegmentRoute;;
// Route defininition for enabling appending of a PuSH Subscription's lookup key
$route = SegmentRoute::factory([
'route' => '/callback/:subkey',
'constraints' => [
'subkey' => '[a-z0-9]+',
],
'defaults' => [
'controller' => 'application-index',
'action' => 'index',
]
]);
```

825
web/vendor/zendframework/zend-feed/doc/book/reader.md vendored Normal file
View file

@ -0,0 +1,825 @@
# Zend\\Feed\\Reader
`Zend\Feed\Reader` is a component used to consume RSS and Atom feeds of
any version, including RDF/RSS 1.0, RSS 2.0, Atom 0.3, and Atom 1.0. The API for
retrieving feed data is deliberately simple since `Zend\Feed\Reader` is capable
of searching any feed of any type for the information requested through the API.
If the typical elements containing this information are not present, it will
adapt and fall back on a variety of alternative elements instead. This ability
to choose from alternatives removes the need for users to create their own
abstraction layer on top of the component to make it useful or have any in-depth
knowledge of the underlying standards, current alternatives, and namespaced
extensions.
Internally, the `Zend\Feed\Reader\Reader` class works almost entirely on the
basis of making XPath queries against the feed XML's Document Object Model. This
singular approach to parsing is consistent, and the component offers a plugin
system to add to the Feed and Entry APIs by writing extensions on a similar
basis.
Performance is assisted in three ways. First of all, `Zend\Feed\Reader\Reader`
supports caching using [zend-cache](https://github.com/zendframework/zend-cache)
to maintain a copy of the original feed XML. This allows you to skip network
requests for a feed URI if the cache is valid. Second, the Feed and Entry APIs
are backed by an internal cache (non-persistent) so repeat API calls for the
same feed will avoid additional DOM or XPath use. Thirdly, importing feeds from
a URI can take advantage of HTTP Conditional `GET` requests which allow servers
to issue an empty 304 response when the requested feed has not changed since the
last time you requested it. In the final case, an zend-cache storage instance
will hold the last received feed along with the ETag and Last-Modified header
values sent in the HTTP response.
`Zend\Feed\Reader\Reader` is not capable of constructing feeds, and delegates
this responsibility to `Zend\Feed\Writer\Writer`.
## Importing Feeds
Feeds can be imported from a string, file or a URI. Importing from a URI can
additionally utilise an HTTP Conditional `GET` request. If importing fails, an
exception will be raised. The end result will be an object of type
`Zend\Feed\Reader\Feed\AbstractFeed`, the core implementations of which are
`Zend\Feed\Reader\Feed\Rss` and `Zend\Feed\Reader\Feed\Atom`. Both objects
support multiple (all existing) versions of these broad feed types.
In the following example, we import an RDF/RSS 1.0 feed and extract some basic
information that can be saved to a database or elsewhere.
```php
$feed = Zend\Feed\Reader\Reader::import('http://www.planet-php.net/rdf/');
$data = [
'title' => $feed->getTitle(),
'link' => $feed->getLink(),
'dateModified' => $feed->getDateModified(),
'description' => $feed->getDescription(),
'language' => $feed->getLanguage(),
'entries' => [],
];
foreach ($feed as $entry) {
$edata = [
'title' => $entry->getTitle(),
'description' => $entry->getDescription(),
'dateModified' => $entry->getDateModified(),
'authors' => $entry->getAuthors(),
'link' => $entry->getLink(),
'content' => $entry->getContent(),
];
$data['entries'][] = $edata;
}
```
> ## Importing requires an HTTP client
>
> To import a feed, you will need to have an [HTTP client](zend.feed.http-clients)
> available.
>
> If you are not using zend-http, you will need to inject `Reader` with the HTTP
> client. See the [section on providing a client to Reader](http-clients.md#providing-a-client-to-reader).
The example above demonstrates `Zend\Feed\Reader\Reader`'s API, and it also
demonstrates some of its internal operation. In reality, the RDF feed selected
does not have any native date or author elements; however it does utilise the
Dublin Core 1.1 module which offers namespaced creator and date elements.
`Zend\Feed\Reader\Reader` falls back on these and similar options if no relevant
native elements exist. If it absolutely cannot find an alternative it will
return `NULL`, indicating the information could not be found in the feed. You
should note that classes implementing `Zend\Feed\Reader\Feed\AbstractFeed` also
implement the SPL `Iterator` and `Countable` interfaces.
Feeds can also be imported from strings or files.
```php
// from a URI
$feed = Zend\Feed\Reader\Reader::import('http://www.planet-php.net/rdf/');
// from a String
$feed = Zend\Feed\Reader\Reader::importString($feedXmlString);
// from a file
$feed = Zend\Feed\Reader\Reader::importFile('./feed.xml');
```
## Retrieving Underlying Feed and Entry Sources
`Zend\Feed\Reader\Reader` does its best not to stick you in a narrow confine. If
you need to work on a feed outside of `Zend\Feed\Reader\Reader`, you can extract
the base DOMDocument or DOMElement objects from any class, or even an XML
string containing these. Also provided are methods to extract the current
DOMXPath object (with all core and extension namespaces registered) and the
correct prefix used in all XPath queries for the current feed or entry. The
basic methods to use (on any object) are `saveXml()`, `getDomDocument()`,
`getElement()`, `getXpath()` and `getXpathPrefix()`. These will let you break
free of `Zend\Feed\Reader` and do whatever else you want.
- `saveXml()` returns an XML string containing only the element representing the
current object.
- `getDomDocument()` returns the DOMDocument object representing the entire feed
(even if called from an entry object).
- `getElement()` returns the DOMElement of the current object (i.e. the feed or
current entry).
- `getXpath()` returns the DOMXPath object for the current feed (even if called
from an entry object) with the namespaces of the current feed type and all
loaded extensions pre-registered.
- `getXpathPrefix()` returns the query prefix for the current object (i.e. the
feed or current entry) which includes the correct XPath query path for that
specific feed or entry.
Let's look at an example where a feed might include an RSS extension not
supported by `Zend\Feed\Reader\Reader` out of the box. Notably, you could write
and register an extension (covered later) to do this, but that's not always
warranted for a quick check. You must register any new namespaces on the
DOMXPath object before use unless they are registered by `Zend\Feed\Reader` or
an extension beforehand.
```php
$feed = Zend\Feed\Reader\Reader::import('http://www.planet-php.net/rdf/');
$xpathPrefix = $feed->getXpathPrefix();
$xpath = $feed->getXpath();
$xpath->registerNamespace('admin', 'http://webns.net/mvcb/');
$reportErrorsTo = $xpath->evaluate(
'string(' . $xpathPrefix . '/admin:errorReportsTo)'
);
```
> ### Do not register duplicate namespaces
>
> If you register an already registered namespace with a different prefix name
> to that used internally by `Zend\Feed\Reader\Reader`, it will break the
> internal operation of this component.
## Cache Support and Intelligent Requests
### Adding Cache Support to Zend\\Feed\\Reader\\Reader
`Zend\Feed\Reader\Reader` supports using a
[zend-cache](https://github.com/zendframework/zend-cache) storage instance to
cache feeds (as XML) to avoid unnecessary network requests. To add a cache,
create and configure your cache instance, and then tell
`Zend\Feed\Reader\Reader` to use it. The cache key used is
"`Zend\Feed\Reader\\`" followed by the MD5 hash of the feed's URI.
```php
$cache = Zend\Cache\StorageFactory::adapterFactory('Memory');
Zend\Feed\Reader\Reader::setCache($cache);
```
### HTTP Conditional GET Support
The big question often asked when importing a feed frequently is if it has even
changed. With a cache enabled, you can add HTTP Conditional `GET` support to
your arsenal to answer that question.
Using this method, you can request feeds from URIs and include their last known
ETag and Last-Modified response header values with the request (using the
If-None-Match and If-Modified-Since headers). If the feed on the server remains
unchanged, you should receive a 304 response which tells
`Zend\Feed\Reader\Reader` to use the cached version. If a full feed is sent in a
response with a status code of 200, this means the feed has changed and
`Zend\Feed\Reader\Reader` will parse the new version and save it to the cache.
It will also cache the new ETag and Last-Modified header values for future use.
> #### Conditional GET requires a HeaderAwareClientInterface
>
> Conditional GET support only works for `Zend\Feed\Reader\Http\HeaderAwareClientInterface`
> client implementations, as it requires the ability to send HTTP headers.
These "conditional" requests are not guaranteed to be supported by the server
you request a *URI* of, but can be attempted regardless. Most common feed
sources like blogs should however have this supported. To enable conditional
requests, you will need to provide a cache to `Zend\Feed\Reader\Reader`.
```php
$cache = Zend\Cache\StorageFactory::adapterFactory('Memory');
Zend\Feed\Reader\Reader::setCache($cache);
Zend\Feed\Reader\Reader::useHttpConditionalGet();
$feed = Zend\Feed\Reader\Reader::import('http://www.planet-php.net/rdf/');
```
In the example above, with HTTP Conditional `GET` requests enabled, the response
header values for ETag and Last-Modified will be cached along with the feed. For
the the cache's lifetime, feeds will only be updated on the cache if a non-304
response is received containing a valid RSS or Atom XML document.
If you intend on managing request headers from outside
`Zend\Feed\Reader\Reader`, you can set the relevant If-None-Matches and
If-Modified-Since request headers via the URI import method.
```php
$lastEtagReceived = '5e6cefe7df5a7e95c8b1ba1a2ccaff3d';
$lastModifiedDateReceived = 'Wed, 08 Jul 2009 13:37:22 GMT';
$feed = Zend\Feed\Reader\Reader::import(
$uri, $lastEtagReceived, $lastModifiedDateReceived
);
```
## Locating Feed URIs from Websites
These days, many websites are aware that the location of their XML feeds is not
always obvious. A small RDF, RSS, or Atom graphic helps when the user is reading
the page, but what about when a machine visits trying to identify where your
feeds are located? To assist in this, websites may point to their feeds using
`<link>` tags in the `<head>` section of their HTML. To take advantage
of this, you can use `Zend\Feed\Reader\Reader` to locate these feeds using the
static `findFeedLinks()` method.
This method calls any URI and searches for the location of RSS, RDF, and Atom
feeds assuming, the website's HTML contains the relevant links. It then returns
a value object where you can check for the existence of a RSS, RDF or Atom feed
URI.
The returned object is an `ArrayObject` subclass called
`Zend\Feed\Reader\FeedSet`, so you can cast it to an array or iterate over it to
access all the detected links. However, as a simple shortcut, you can just grab
the first RSS, RDF, or Atom link using its public properties as in the example
below. Otherwise, each element of the `ArrayObject` is a simple array with the
keys `type` and `uri` where the type is one of "rdf", "rss", or "atom".
```php
$links = Zend\Feed\Reader\Reader::findFeedLinks('http://www.planet-php.net');
if (isset($links->rdf)) {
echo $links->rdf, "\n"; // http://www.planet-php.org/rdf/
}
if (isset($links->rss)) {
echo $links->rss, "\n"; // http://www.planet-php.org/rss/
}
if (isset($links->atom)) {
echo $links->atom, "\n"; // http://www.planet-php.org/atom/
}
```
Based on these links, you can then import from whichever source you wish in the usual manner.
> ### Finding feed links requires an HTTP client
>
> To find feed links, you will need to have an [HTTP client](zend.feed.http-clients)
> available.
>
> If you are not using zend-http, you will need to inject `Reader` with the HTTP
> client. See the [section on providing a client to Reader](http-clients.md#providing-a-client-to-reader).
This quick method only gives you one link for each feed type, but websites may
indicate many links of any type. Perhaps it's a news site with a RSS feed for
each news category. You can iterate over all links using the ArrayObject's
iterator.
```php
$links = Zend\Feed\Reader::findFeedLinks('http://www.planet-php.net');
foreach ($links as $link) {
echo $link['href'], "\n";
}
```
## Attribute Collections
In an attempt to simplify return types, return types from the various feed and
entry level methods may include an object of type
`Zend\Feed\Reader\Collection\AbstractCollection`. Despite the special class name
which I'll explain below, this is just a simple subclass of SPL's `ArrayObject`.
The main purpose here is to allow the presentation of as much data as possible
from the requested elements, while still allowing access to the most relevant
data as a simple array. This also enforces a standard approach to returning such
data which previously may have wandered between arrays and objects.
The new class type acts identically to `ArrayObject` with the sole addition
being a new method `getValues()` which returns a simple flat array containing
the most relevant information.
A simple example of this is `Zend\Feed\Reader\Reader\FeedInterface::getCategories()`.
When used with any RSS or Atom feed, this method will return category data as a
container object called `Zend\Feed\Reader\Collection\Category`. The container
object will contain, per category, three fields of data: term, scheme, and label.
The "term" is the basic category name, often machine readable (i.e. plays nice
with URIs). The scheme represents a categorisation scheme (usually a URI
identifier) also known as a "domain" in RSS 2.0. The "label" is a human readable
category name which supports HTML entities. In RSS 2.0, there is no label
attribute so it is always set to the same value as the term for convenience.
To access category labels by themselves in a simple value array, you might
commit to something like:
```php
$feed = Zend\Feed\Reader\Reader::import('http://www.example.com/atom.xml');
$categories = $feed->getCategories();
$labels = [];
foreach ($categories as $cat) {
$labels[] = $cat['label']
}
```
It's a contrived example, but the point is that the labels are tied up with
other information.
However, the container class allows you to access the "most relevant" data as a
simple array using the `getValues()` method. The concept of "most relevant" is
obviously a judgement call. For categories it means the category labels (not the
terms or schemes) while for authors it would be the authors' names (not their
email addresses or URIs). The simple array is flat (just values) and passed
through `array_unique()` to remove duplication.
```php
$feed = Zend\Feed\Reader\Reader::import('http://www.example.com/atom.xml');
$categories = $feed->getCategories();
$labels = $categories->getValues();
```
The above example shows how to extract only labels and nothing else thus giving
simple access to the category labels without any additional work to extract that
data by itself.
## Retrieving Feed Information
Retrieving information from a feed (we'll cover entries and items in the next
section though they follow identical principals) uses a clearly defined API
which is exactly the same regardless of whether the feed in question is RSS,
RDF, or Atom. The same goes for sub-versions of these standards and we've tested
every single RSS and Atom version. While the underlying feed XML can differ
substantially in terms of the tags and elements they present, they nonetheless
are all trying to convey similar information and to reflect this all the
differences and wrangling over alternative tags are handled internally by
`Zend\Feed\Reader\Reader` presenting you with an identical interface for each.
Ideally, you should not have to care whether a feed is RSS or Atom so long as
you can extract the information you want.
> ### RSS feeds vary widely
>
> While determining common ground between feed types is itself complex, it
> should be noted that *RSS* in particular is a constantly disputed
> "specification". This has its roots in the original RSS 2.0 document, which
> contains ambiguities and does not detail the correct treatment of all
> elements. As a result, this component rigorously applies the RSS 2.0.11
> Specification published by the RSS Advisory Board and its accompanying RSS
> Best Practices Profile. No other interpretation of RSS
> 2.0 will be supported, though exceptions may be allowed where it does not
> directly prevent the application of the two documents mentioned above.
Of course, we don't live in an ideal world, so there may be times the API just
does not cover what you're looking for. To assist you, `Zend\Feed\Reader\Reader`
offers a plugin system which allows you to write extensions to expand the core
API and cover any additional data you are trying to extract from feeds. If
writing another extension is too much trouble, you can simply grab the
underlying DOM or XPath objects and do it by hand in your application. Of
course, we really do encourage writing an extension simply to make it more
portable and reusable, and useful extensions may be proposed to the component
for formal addition.
Below is a summary of the Core API for feeds. You should note it comprises not
only the basic RSS and Atom standards, but also accounts for a number of
included extensions bundled with `Zend\Feed\Reader\Reader`. The naming of these
extension sourced methods remain fairly generic; all Extension methods operate
at the same level as the Core API though we do allow you to retrieve any
specific extension object separately if required.
### Feed Level API Methods
Method | Description
------ | -----------
`getId()` | Returns a unique ID associated with this feed
`getTitle()` | Returns the title of the feed
`getDescription()` | Returns the text description of the feed.
`getLink()` | Returns a URI to the HTML website containing the same or similar information as this feed (i.e. if the feed is from a blog, it should provide the blog's URI where the HTML version of the entries can be read).
`getFeedLink()` | Returns the URI of this feed, which may be the same as the URI used to import the feed. There are important cases where the feed link may differ because the source URI is being updated and is intended to be removed in the future.
`getAuthors()` | Returns an object of type `Zend\Feed\Reader\Collection\Author` which is an `ArrayObject` whose elements are each simple arrays containing any combination of the keys "name", "email" and "uri". Where irrelevant to the source data, some of these keys may be omitted.
`getAuthor(integer $index = 0)` | Returns either the first author known, or with the optional $index parameter any specific index on the array of authors as described above (returning `NULL` if an invalid index).
`getDateCreated()` | Returns the date on which this feed was created. Generally only applicable to Atom, where it represents the date the resource described by an Atom 1.0 document was created. The returned date will be a `DateTime` object.
`getDateModified()` | Returns the date on which this feed was last modified. The returned date will be a `DateTime` object.
`getLastBuildDate()` | Returns the date on which this feed was last built. The returned date will be a `DateTime` object. This is only supported by RSS; Atom feeds will always return `NULL`.
`getLanguage()` | Returns the language of the feed (if defined) or simply the language noted in the XML document.
`getGenerator()` | Returns the generator of the feed, e.g. the software which generated it. This may differ between RSS and Atom since Atom defines a different notation.
`getCopyright()` | Returns any copyright notice associated with the feed.
`getHubs()` | Returns an array of all Hub Server URI endpoints which are advertised by the feed for use with the Pubsubhubbub Protocol, allowing subscriptions to the feed for real-time updates.
`getCategories()` | Returns a `Zend\Feed\Reader\Collection\Category` object containing the details of any categories associated with the overall feed. The supported fields include "term" (the machine readable category name), "scheme" (the categorisation scheme and domain for this category), and "label" (a HTML decoded human readable category name). Where any of the three fields are absent from the field, they are either set to the closest available alternative or, in the case of "scheme", set to `NULL`.
`getImage()` | Returns an array containing data relating to any feed image or logo, or `NULL` if no image found. The resulting array may contain the following keys: uri, link, title, description, height, and width. Atom logos only contain a URI so the remaining metadata is drawn from RSS feeds only.
Given the variety of feeds in the wild, some of these methods will undoubtedly
return `NULL` indicating the relevant information couldn't be located. Where
possible, `Zend\Feed\Reader\Reader` will fall back on alternative elements
during its search. For example, searching an RSS feed for a modification date is
more complicated than it looks. RSS 2.0 feeds should include a `<lastBuildDate>`
tag and/or a `<pubDate>` element. But what if it doesn't? Maybe this is an RSS
1.0 feed? Perhaps it instead has an `<atom:updated>` element with identical
information (Atom may be used to supplement RSS syntax)? Failing that, we
could simply look at the entries, pick the most recent, and use its `<pubDate>`
element. Assuming it exists, that is. Many feeds also use Dublin Core 1.0 or 1.1
`<dc:date>` elements for feeds and entries. Or we could find Atom lurking again.
The point is, `Zend\Feed\Reader\Reader` was designed to know this. When you ask
for the modification date (or anything else), it will run off and search for all
these alternatives until it either gives up and returns `NULL`, or finds an
alternative that should have the right answer.
In addition to the above methods, all feed objects implement methods for
retrieving the DOM and XPath objects for the current feeds as described
earlier. Feed objects also implement the SPL Iterator and Countable
interfaces. The extended API is summarised below.
### Extended Feed API Methods
Method | Description
------ | -----------
`getDomDocument()` | Returns the parent DOMDocument object for the entire source XML document.
`getElement()` | Returns the current feed level DOMElement object.
`saveXml()` | Returns a string containing an XML document of the entire feed element (this is not the original document, but a rebuilt version).
`getXpath()` | Returns the DOMXPath object used internally to run queries on the DOMDocument object (this includes core and extension namespaces pre-registered).
`getXpathPrefix()` | Returns the valid DOM path prefix prepended to all XPath queries matching the feed being queried.
`getEncoding()` | Returns the encoding of the source XML document (note: this cannot account for errors such as the server sending documents in a different encoding). Where not defined, the default UTF-8 encoding of Unicode is applied.
`count()` | Returns a count of the entries or items this feed contains (implements SPL `Countable` interface)
`current()` | Returns either the current entry (using the current index from `key()`).
`key()` | Returns the current entry index.
`next()` | Increments the entry index value by one.
`rewind()` | Resets the entry index to 0.
`valid()` | Checks that the current entry index is valid, i.e. it does not fall below 0 and does not exceed the number of entries existing.
`getExtensions()` | Returns an array of all extension objects loaded for the current feed (note: both feed-level and entry-level extensions exist, and only feed-level extensions are returned here). The array keys are of the form `{ExtensionName}_Feed`.
`getExtension(string $name)` | Returns an extension object for the feed registered under the provided name. This allows more fine-grained access to extensions which may otherwise be hidden within the implementation of the standard API methods.
`getType()` | Returns a static class constant (e.g. `Zend\Feed\Reader\Reader::TYPE_ATOM_03`, i.e. "Atom 0.3"), indicating exactly what kind of feed is being consumed.
## Retrieving Entry/Item Information
Retrieving information for specific entries or items (depending on whether you
speak Atom or RSS) is identical to feed level data. Accessing entries is
simply a matter of iterating over a feed object or using the SPL `Iterator`
interface feed objects implement, and calling the appropriate method on each.
### Entry API Methods
Method | Description
------ | -----------
`getId()` | Returns a unique ID for the current entry.
`getTitle()` | Returns the title of the current entry.
`getDescription()` | Returns a description of the current entry.
`getLink()` | Returns a URI to the HTML version of the current entry.
`getPermaLink()` | Returns the permanent link to the current entry. In most cases, this is the same as using `getLink()`.
`getAuthors()` | Returns an object of type `Zend\Feed\Reader\Collection\Author`, which is an `ArrayObject` whose elements are each simple arrays containing any combination of the keys "name", "email" and "uri". Where irrelevant to the source data, some of these keys may be omitted.
`getAuthor(integer $index = 0)` | Returns either the first author known, or, with the optional `$index` parameter, any specific index on the array of Authors as described above (returning `NULL` if an invalid index).
`getDateCreated()` | Returns the date on which the current entry was created. Generally only applicable to Atom where it represents the date the resource described by an Atom 1.0 document was created.
`getDateModified()` | Returns the date on which the current entry was last modified.
`getContent()` | Returns the content of the current entry (this has any entities reversed if possible, assuming the content type is HTML). The description is returned if a separate content element does not exist.
`getEnclosure()` | Returns an array containing the value of all attributes from a multi-media `<enclosure>` element including as array keys: url, length, type. In accordance with the RSS Best Practices Profile of the RSS Advisory Board, no support is offers for multiple enclosures since such support forms no part of the RSS specification.
`getCommentCount()` | Returns the number of comments made on this entry at the time the feed was last generated.
`getCommentLink()` | Returns a URI pointing to the HTML page where comments can be made on this entry.
`getCommentFeedLink([string $type = ‘atom'|'rss'])` | Returns a URI pointing to a feed of the provided type containing all comments for this entry (type defaults to Atom/RSS depending on current feed type).
`getCategories()` | Returns a `Zend\Feed\Reader\Collection\Category` object containing the details of any categories associated with the entry. The supported fields include "term" (the machine readable category name), "scheme" (the categorisation scheme and domain for this category), and "label" (an HTML-decoded human readable category name). Where any of the three fields are absent from the field, they are either set to the closest available alternative or, in the case of "scheme", set to `NULL`.
The extended API for entries is identical to that for feeds with the exception
of the `Iterator` methods, which are not needed here.
> ### Modified vs Created dates
>
> There is often confusion over the concepts of *modified* and *created* dates.
> In Atom, these are two clearly defined concepts (so knock yourself out) but in
> RSS they are vague. RSS 2.0 defines a single `<pubDate>` element which
> typically refers to the date this entry was published, i.e. a creation date of
> sorts. This is not always the case, and it may change with updates or not. As a
> result, if you really want to check whether an entry has changed, don't rely on
> the results of `getDateModified()`. Instead, consider tracking the MD5 hash of
> three other elements concatenated, e.g. using `getTitle()`, `getDescription()`,
> and `getContent()`. If the entry was truly updated, this hash computation will
> give a different result than previously saved hashes for the same entry. This
> is obviously content oriented, and will not assist in detecting changes to
> other relevant elements. Atom feeds should not require such steps.
> Further muddying the waters, dates in feeds may follow different standards.
> Atom and Dublin Core dates should follow ISO 8601, and RSS dates should
> follow RFC 822 or RFC 2822 (which is also common). Date methods will throw an
> exception if `DateTime` cannot load the date string using one of the above
> standards, or the PHP recognised possibilities for RSS dates.
> ### Validation
>
> The values returned from these methods are not validated. This means users
> must perform validation on all retrieved data including the filtering of any
> HTML such as from `getContent()` before it is output from your application.
> Remember that most feeds come from external sources, and therefore the default
> assumption should be that they cannot be trusted.
### Extended Entry Level API Methods
Method | Description
------ | -----------
`getDomDocument()` | Returns the parent DOMDocument object for the entire feed (not just the current entry).
`getElement()` | Returns the current entry level DOMElement object.
`getXpath()` | Returns the DOMXPath object used internally to run queries on the DOMDocument object (this includes core and extension namespaces pre-registered).
`getXpathPrefix()` | Returns the valid DOM path prefix prepended to all XPath queries matching the entry being queried.
`getEncoding()` | Returns the encoding of the source XML document (note: this cannot account for errors such as the server sending documents in a different encoding). The default encoding applied in the absence of any other is the UTF-8 encoding of Unicode.
`getExtensions()` | Returns an array of all extension objects loaded for the current entry (note: both feed-level and entry-level extensions exist, and only entry-level extensions are returned here). The array keys are in the form `{ExtensionName}Entry`.
`getExtension(string $name)` | Returns an extension object for the entry registered under the provided name. This allows more fine-grained access to extensions which may otherwise be hidden within the implementation of the standard API methods.
`getType()` | Returns a static class constant (e.g. `Zend\Feed\Reader\Reader::TYPE_ATOM_03`, i.e. "Atom 0.3") indicating exactly what kind of feed is being consumed.
## Extending Feed and Entry APIs
Extending `Zend\Feed\Reader\Reader` allows you to add methods at both the feed
and entry level which cover the retrieval of information not already supported
by `Zend\Feed\Reader\Reader`. Given the number of RSS and Atom extensions that
exist, this is a good thing, since `Zend\Feed\Reader\Reader` couldn't possibly
add everything.
There are two types of extensions possible, those which retrieve information
from elements which are immediate children of the root element (e.g.
`<channel>` for RSS or `<feed>` for Atom), and those who retrieve information
from child elements of an entry (e.g. `<item>` for RSS or `<entry>` for Atom).
On the filesystem, these are grouped as classes within a namespace based on the
extension standard's name. For example, internally we have
`Zend\Feed\Reader\Extension\DublinCore\Feed` and
`Zend\Feed\Reader\Extension\DublinCore\Entry` classes which are two extensions
implementing Dublin Core 1.0 and 1.1 support.
Extensions are loaded into `Zend\Feed\Reader\Reader` using an "extension
manager". Extension managers must implement `Zend\Feed\Reader\ExtensionManagerInterface`.
Three implementations exist:
- `Zend\Feed\Reader\StandaloneExtensionManager` is a hard-coded implementation
seeded with all feed and entry implementations. You can extend it to add
extensions, though it's likely easier to copy and paste it, adding your
changes.
- `Zend\Feed\Reader\ExtensionPluginManager` is a `Zend\ServiceManager\AbstractPluginManager`
implementation, `Zend\Feed\Reader\ExtensionManager`; as such, you can extend
it to add more extensions, use a `Zend\ServiceManager\ConfigInterface` instance
to inject it with more extensions, or use its public API for adding services
(e.g., `setService()`, `setFactory()`, etc.). This implementation *does not*
implement `ExtensionManagerInterface`, and must be used with `ExtensionManager`.
- `Zend\Feed\Reader\ExtensionManager` exists for legacy purposes; prior to 2.3,
this was an `AbstractPluginManager` implementation, and the only provided
extension manager. It now implements `ExtensionManagerInterface`, and acts as
a decorator for `ExtensionPluginManager`.
By default, `Zend\Feed\Reader\Reader` composes a `StandaloneExtensionManager`. You
can inject an alternate implementation using `Reader::setExtensionManager()`:
```php
$extensions = new Zend\Feed\Reader\ExtensionPluginManager();
Zend\Feed\Reader\Reader::setExtensionManager(
new ExtensionManager($extensions)
);
```
The shipped implementations all provide the default extensions (so-called
"Core Extensions") used internally by `Zend\Feed\Reader\Reader`. These
include:
Extension | Description
--------- | -----------
DublinCore (Feed and Entry) | Implements support for Dublin Core Metadata Element Set 1.0 and 1.1.
Content (Entry only) | Implements support for Content 1.0.
Atom (Feed and Entry) | Implements support for Atom 0.3 and Atom 1.0.
Slash | Implements support for the Slash RSS 1.0 module.
WellFormedWeb | Implements support for the Well Formed Web CommentAPI 1.0.
Thread | Implements support for Atom Threading Extensions as described in RFC 4685.
Podcast | Implements support for the Podcast 1.0 DTD from Apple.
The core extensions are somewhat special since they are extremely common and
multi-faceted. For example, we have a core extension for Atom. Atom is
implemented as an extension (not just a base class) because it doubles as a
valid RSS module; you can insert Atom elements into RSS feeds. I've even seen
RDF feeds which use a lot of Atom in place of more common extensions like
Dublin Core.
The following is a list of non-Core extensions that are offered, but not registered
by default. If you want to use them, you'll need to
tell `Zend\Feed\Reader\Reader` to load them in advance of importing a feed.
Additional non-Core extensions will be included in future iterations of the
component.
Extension | Description
--------- | -----------
Syndication | Implements Syndication 1.0 support for RSS feeds.
CreativeCommons | An RSS module that adds an element at the `<channel>` or `<item>` level that specifies which Creative Commons license applies.
`Zend\Feed\Reader\Reader` requires you to explicitly register non-Core
extensions in order to expose their API to feed and entry objects. Below, we
register the optional Syndication extension, and discover that it can be
directly called from the entry API without any effort. (Note that
extension names are case sensitive and use camelCasing for multiple terms.)
```php
use Zend\Feed\Reader\Reader;
Reader::registerExtension('Syndication');
$feed = Reader::import('http://rss.slashdot.org/Slashdot/slashdot');
$updatePeriod = $feed->getUpdatePeriod();
```
In the simple example above, we checked how frequently a feed is being updated
using the `getUpdatePeriod()` method. Since it's not part of
`Zend\Feed\Reader\Reader`'s core API, it could only be a method supported by
the newly registered Syndication extension.
As you can also notice, methods provided by extensions are accessible from the
main API using method overloading. As an alternative, you can also directly
access any extension object for a similar result as seen below.
```php
use Zend\Feed\Reader\Reader;
Reader::registerExtension('Syndication');
$feed = Reader::import('http://rss.slashdot.org/Slashdot/slashdot');
$syndication = $feed->getExtension('Syndication');
$updatePeriod = $syndication->getUpdatePeriod();
```
### Writing Zend\\Feed\\Reader Extensions
Inevitably, there will be times when the `Zend\Feed\Reader` API is just
not capable of getting something you need from a feed or entry. You can use the
underlying source objects, like DOMDocument, to get these by hand; however, there
is a more reusable method available: you can write extensions supporting these new
queries.
As an example, let's take the case of a purely fictitious corporation named
Jungle Books. Jungle Books have been publishing a lot of reviews on books they
sell (from external sources and customers), which are distributed as an RSS 2.0
feed. Their marketing department realises that web applications using this feed
cannot currently figure out exactly what book is being reviewed. To make life
easier for everyone, they determine that the geek department needs to extend
RSS 2.0 to include a new element per entry supplying the ISBN-10 or ISBN-13
number of the publication the entry concerns. They define the new `<isbn>`
element quite simply with a standard name and namespace URI:
- Name: JungleBooks 1.0
- Namespace URI: http://example.com/junglebooks/rss/module/1.0/
A snippet of RSS containing this extension in practice could be something
similar to:
```xml
<?xml version="1.0" encoding="utf-8" ?>
<rss version="2.0"
xmlns:content="http://purl.org/rss/1.0/modules/content/"
xmlns:jungle="http://example.com/junglebooks/rss/module/1.0/">
<channel>
<title>Jungle Books Customer Reviews</title>
<link>http://example.com/junglebooks</link>
<description>Many book reviews!</description>
<pubDate>Fri, 26 Jun 2009 19:15:10 GMT</pubDate>
<jungle:dayPopular>
http://example.com/junglebooks/book/938
</jungle:dayPopular>
<item>
<title>Review Of Flatland: A Romance of Many Dimensions</title>
<link>http://example.com/junglebooks/review/987</link>
<author>Confused Physics Student</author>
<content:encoded>
A romantic square?!
</content:encoded>
<pubDate>Thu, 25 Jun 2009 20:03:28 -0700</pubDate>
<jungle:isbn>048627263X</jungle:isbn>
</item>
</channel>
</rss>
```
Implementing this new ISBN element as a simple entry level extension would
require the following class (using your own namespace).
```php
namespace My\FeedReader\Extension\JungleBooks;
use Zend\Feed\Reader\Extension\AbstractEntry;
class Entry extends AbstractEntry
{
public function getIsbn()
{
if (isset($this->data['isbn'])) {
return $this->data['isbn'];
}
$isbn = $this->xpath->evaluate(
'string(' . $this->getXpathPrefix() . '/jungle:isbn)'
);
if (! $isbn) {
$isbn = null;
}
$this->data['isbn'] = $isbn;
return $this->data['isbn'];
}
protected function registerNamespaces()
{
$this->xpath->registerNamespace(
'jungle',
'http://example.com/junglebooks/rss/module/1.0/'
);
}
}
```
This extension creates a new method `getIsbn()`, which runs an XPath query on
the current entry to extract the ISBN number enclosed by the `<jungle:isbn>`
element. It can optionally store this to the internal non-persistent cache (no
need to keep querying the DOM if it's called again on the same entry). The
value is returned to the caller. At the end we have a protected method (it's
abstract, making it required by implementations) which registers the Jungle
Books namespace for their custom RSS module. While we call this an RSS module,
there's nothing to prevent the same element being used in Atom feeds; all
extensions which use the prefix provided by `getXpathPrefix()` are actually
neutral and work on RSS or Atom feeds with no extra code.
Since this extension is stored outside of zend-feed, you'll need to ensure your
application can autoload it. Once that's in place, you will also need to ensure
your extension manager knows about it, and then register the extension with
`Zend\Feed\Reader\Reader`.
The following example uses `Zend\Feed\Reader\ExtensionPluginManager` to manage
extensions, as it provides the ability to register new extensions without
requiring extension of the plugin manager itself. To use it, first intall
zend-servicemanager:
```bash
$ composer require zendframework/zend-servicemanager
```
From there:
```php
use My\FeedReader\Extension\JungleBooks;
use Zend\Feed\Reader\ExtensionManager;
use Zend\Feed\Reader\ExtensionPluginManager;
use Zend\Feed\Reader\Reader;
$extensions = new ExtensionPluginManager();
$extensions->setInvokableClass('JungleBooks\Entry', JungleBooks\Entry::class);
Reader::setExtensionManager(new ExtensionManager($extensions));
Reader::registerExtension('JungleBooks');
$feed = Reader::import('http://example.com/junglebooks/rss');
// ISBN for whatever book the first entry in the feed was concerned with
$firstIsbn = $feed->current()->getIsbn();
```
Writing a feed extension is not much different. The example feed from earlier
included an unmentioned `<jungle:dayPopular>` element which Jungle Books have
added to their standard to include a link to the day's most popular book (in
terms of visitor traffic). Here's an extension which adds a
`getDaysPopularBookLink()` method to the feel level API.
```php
namespace My\FeedReader\Extension\JungleBooks;
use Zend\Feed\Reader\Extension\AbstractFeed;
class Feed extends AbstractFeed
{
public function getDaysPopularBookLink()
{
if (isset($this->data['dayPopular'])) {
return $this->data['dayPopular'];
}
$dayPopular = $this->xpath->evaluate(
'string(' . $this->getXpathPrefix() . '/jungle:dayPopular)'
);
if (!$dayPopular) {
$dayPopular = null;
}
$this->data['dayPopular'] = $dayPopular;
return $this->data['dayPopular'];
}
protected function registerNamespaces()
{
$this->xpath->registerNamespace(
'jungle',
'http://example.com/junglebooks/rss/module/1.0/'
);
}
}
```
Let's add to the previous example; we'll register the new class with the
extension manager, and then demonstrate using the newly exposed method:
```php
use My\FeedReader\Extension\JungleBooks;
use Zend\Feed\Reader\ExtensionManager;
use Zend\Feed\Reader\ExtensionPluginManager;
use Zend\Feed\Reader\Reader;
$extensions = new ExtensionPluginManager();
$extensions->setInvokableClass('JungleBooks\Entry', JungleBooks\Entry::class);
$extensions->setInvokableClass('JungleBooks\Feed', JungleBooks\Feed::class);
Reader::setExtensionManager(new ExtensionManager($extensions));
Reader::registerExtension('JungleBooks');
$feed = Reader::import('http://example.com/junglebooks/rss');
// URI to the information page of the day's most popular book with visitors
$daysPopularBookLink = $feed->getDaysPopularBookLink();
```
Going through these examples, you'll note that while we need to register the
feed and entry classes separately with the plugin manager, we don't register
them separately when registering the extension with the `Reader`. Extensions
within the same standard may or may not include both a feed and entry class, so
`Zend\Feed\Reader\Reader` only requires you to register the overall parent name,
e.g. JungleBooks, DublinCore, Slash. Internally, it can check at what level
extensions exist and load them up if found. In our case, we have a complete
extension now, spanning the classes `JungleBooks\Feed` and `JungleBooks\Entry`.

161
web/vendor/zendframework/zend-feed/doc/book/security.md vendored Normal file
View file

@ -0,0 +1,161 @@
# Zend\\Feed\\Reader and Security
As with any data coming from a source that is beyond the developer's control,
special attention needs to be given to securing, validating and filtering that
data. Similar to data input to our application by users, data coming from RSS
and Atom feeds should also be considered unsafe and potentially dangerous, as it
allows the delivery of HTML and [xHTML](http://tools.ietf.org/html/rfc4287#section-8.1).
Because data validation and filtration is out of `Zend\Feed`'s scope, this task
is left for implementation by the developer, by using libraries such as
zend-escaper for escaping and [HTMLPurifier](http://www.htmlpurifier.org/) for
validating and filtering feed data.
Escaping and filtering of potentially insecure data is highly recommended before
outputting it anywhere in our application or before storing that data in some
storage engine (be it a simple file or a database.).
## Filtering data using HTMLPurifier
Currently, the best available library for filtering and validating (x)HTML data
in PHP is [HTMLPurifier](http://www.htmlpurifier.org/), and, as such, is the
recommended tool for this task. HTMLPurifier works by filtering out all (x)HTML
from the data, except for the tags and attributes specifically allowed in a
whitelist, and by checking and fixing nesting of tags, ensuring
standards-compliant output.
The following examples will show a basic usage of HTMLPurifier, but developers
are urged to go through and read [HTMLPurifier's documentation](http://www.htmlpurifier.org/docs).
```php
// Setting HTMLPurifier's options
$options = [
// Allow only paragraph tags
// and anchor tags wit the href attribute
[
'HTML.Allowed',
'p,a[href]'
],
// Format end output with Tidy
[
'Output.TidyFormat',
true
],
// Assume XHTML 1.0 Strict Doctype
[
'HTML.Doctype',
'XHTML 1.0 Strict'
],
// Disable cache, but see note after the example
[
'Cache.DefinitionImpl',
null
]
];
// Configuring HTMLPurifier
$config = HTMLPurifier_Config::createDefault();
foreach ($options as $option) {
$config->set($option[0], $option[1]);
}
// Creating a HTMLPurifier with it's config
$purifier = new HTMLPurifier($config);
// Fetch the RSS
try {
$rss = Zend\Feed\Reader\Reader::import('http://www.planet-php.net/rss/');
} catch (Zend\Feed\Exception\Reader\RuntimeException $e) {
// feed import failed
echo "Exception caught importing feed: {$e->getMessage()}\n";
exit;
}
// Initialize the channel data array
// See that we're cleaning the description with HTMLPurifier
$channel = [
'title' => $rss->getTitle(),
'link' => $rss->getLink(),
'description' => $purifier->purify($rss->getDescription()),
'items' => [],
];
// Loop over each channel item and store relevant data
// See that we're cleaning the descriptions with HTMLPurifier
foreach ($rss as $item) {
$channel['items'][] = [
'title' => $item->getTitle(),
'link' => $item->getLink(),
'description' => $purifier->purify($item->getDescription()),
];
}
```
> ### Tidy is required
>
> HTMLPurifier is using the PHP [Tidy extension](http://php.net/tidy) to clean
> and repair the final output. If this extension is not available, it will
> silently fail, but its availability has no impact on the library's security.
> ### Caching
>
> For the sake of this example, the HTMLPurifier's cache is disabled, but it is
> recommended to configure caching and use its standalone include file as it can
> improve the performance of HTMLPurifier substantially.
## Escaping data using zend-escaper
To help prevent XSS attacks, Zend Framework provides the [zend-escaper component](https://github.com/zendframework/zend-escaper),
which complies to the current [OWASP recommendations](https://www.owasp.org/index.php/XSS_Prevention_Cheat_Sheet),
and as such, is the recommended tool for escaping HTML tags and attributes,
Javascript, CSS and URLs before outputing any potentially insecure data to the
users.
```php
try {
$rss = Zend\Feed\Reader\Reader::import('http://www.planet-php.net/rss/');
} catch (Zend\Feed\Exception\Reader\RuntimeException $e) {
// feed import failed
echo "Exception caught importing feed: {$e->getMessage()}\n";
exit;
}
// Validate all URIs
$linkValidator = new Zend\Validator\Uri;
$link = null;
if ($linkValidator->isValid($rss->getLink())) {
$link = $rss->getLink();
}
// Escaper used for escaping data
$escaper = new Zend\Escaper\Escaper('utf-8');
// Initialize the channel data array
$channel = [
'title' => $escaper->escapeHtml($rss->getTitle()),
'link' => $escaper->escapeUrl($link),
'description' => $escaper->escapeHtml($rss->getDescription()),
'items' => [],
];
// Loop over each channel item and store relevant data
foreach ($rss as $item) {
$link = null;
if ($linkValidator->isValid($rss->getLink())) {
$link = $item->getLink();
}
$channel['items'][] = [
'title' => $escaper->escapeHtml($item->getTitle()),
'link' => $escaper->escapeUrl($link),
'description' => $escaper->escapeHtml($item->getDescription()),
];
}
```
The feed data is now safe for output to HTML templates. You can, of course, skip
escaping when simply storing the data persistently, but remember to escape it on
output later!
Of course, these are just basic examples, and cannot cover all possible
scenarios that you, as a developer, can, and most likely will, encounter. Your
responsibility is to learn what libraries and tools are at your disposal, and
when and how to use them to secure your web applications.

280
web/vendor/zendframework/zend-feed/doc/book/writer.md vendored Normal file
View file

@ -0,0 +1,280 @@
# Zend\\Feed\\Writer
`Zend\Feed\Writer` is the sibling component to `Zend\Feed\Reader` responsible
for *generating* feeds. It supports the Atom 1.0 specification (RFC 4287) and
RSS 2.0 as specified by the RSS Advisory Board (RSS 2.0.11). It does not deviate
from these standards. It does, however, offer a simple extension system which
allows for any extension and module for either of these two specifications to be
implemented if they are not provided out of the box.
In many ways, `Zend\Feed\Writer` is the inverse of `Zend\Feed\Reader`. Where
`Zend\Reader\Reader` focuses on providing an easy to use architecture fronted by
getter methods, `Zend\Feed\Writer` is fronted by similarly named setters or
mutators. This ensures the API won't pose a learning curve to anyone familiar
with `Zend\Feed\Reader`.
As a result of this design, the rest may even be obvious. Behind the scenes,
data set on any `Zend\Feed\Writer\Writer` instance is translated at render time
onto a DOMDocument object using the necessary feed elements. For each supported
feed type there is both an Atom 1.0 and RSS 2.0 renderer. Using a DOMDocument
class rather than a templating solution has numerous advantages, the most
obvious being the ability to export the DOMDocument for additional processing
and relying on PHP DOM for correct and valid rendering.
## Architecture
The architecture of `Zend\Feed\Writer` is very simple. It has two core sets of
classes: data containers and renderers.
The containers include the `Zend\Feed\Writer\Feed` and `Zend\Feed\Writer\Entry`
classes. The Entry classes can be attached to any Feed class. The sole purpose
of these containers is to collect data about the feed to generate using a simple
interface of setter methods. These methods perform some data validity testing.
For example, it will validate any passed URIs, dates, etc. These checks are not
tied to any of the feed standards definitions. The container objects also
contain methods to allow for fast rendering and export of the final feed, and
these can be reused at will.
In addition to the main data container classes, there are two additional Atom
2.0-specific classes: `Zend\Feed\Writer\Source` and `Zend\Feed\Writer\Deleted`.
The former implements Atom 2.0 source elements which carry source feed metadata
for a specific entry within an aggregate feed (i.e. the current feed is not the
entry's original source). The latter implements the [Atom Tombstones RFC](https://tools.ietf.org/html/rfc6721),
allowing feeds to carry references to entries which have been deleted.
While there are two main data container types, there are four renderers: two
matching container renderers per supported feed type. Each renderer accepts a
container, and, based on its content, attempts to generate valid feed markup. If
the renderer is unable to generate valid feed markup (perhaps due to the
container missing an obligatory data point), it will report this by throwing an
exception. While it is possible to ignore exceptions, this removes the default
safeguard of ensuring you have sufficient data set to render a wholly valid
feed.
To explain this more clearly: you may construct a set of data containers for a
feed where there is a Feed container, into which has been added some Entry
containers and a Deleted container. This forms a data hierarchy resembling a
normal feed. When rendering is performed, this hierarchy has its pieces passed
to relevant renderers, and the partial feeds (all DOMDocuments) are then pieced
together to create a complete feed. In the case of Source or Deleted (Tombstone)
containers, these are rendered only for Atom 2.0 and ignored for RSS.
Due to the system being divided between data containers and renderers,
extensions have more mandatory requirements than their equivalents in the
`Zend\Feed\Reader` subcomponent. A typical extension offering namespaced feed
and entry level elements must itself reflect the exact same architecture: i.e.
it must offer both feed and entry level data containers, and matching renderers.
There is, fortunately, no complex integration work required since all extension
classes are simply registered and automatically used by the core classes. We
cover extensions in more detail at the end of this chapter.
## Getting Started
To use `Zend\Feed\Writer\Writer`, you will provide it with data, and then
trigger the renderer. What follows is an example demonstrating generation of a
minimal Atom 1.0 feed. Each feed or entry uses a separate data container.
```php
use Zend\Feed\Writer\Feed;
/**
* Create the parent feed
*/
$feed = new Feed;
$feed->setTitle("Paddy's Blog");
$feed->setLink('http://www.example.com');
$feed->setFeedLink('http://www.example.com/atom', 'atom');
$feed->addAuthor([
'name' => 'Paddy',
'email' => 'paddy@example.com',
'uri' => 'http://www.example.com',
]);
$feed->setDateModified(time());
$feed->addHub('http://pubsubhubbub.appspot.com/');
/**
* Add one or more entries. Note that entries must
* be manually added once created.
*/
$entry = $feed->createEntry();
$entry->setTitle('All Your Base Are Belong To Us');
$entry->setLink('http://www.example.com/all-your-base-are-belong-to-us');
$entry->addAuthor([
'name' => 'Paddy',
'email' => 'paddy@example.com',
'uri' => 'http://www.example.com',
]);
$entry->setDateModified(time());
$entry->setDateCreated(time());
$entry->setDescription('Exposing the difficulty of porting games to English.');
$entry->setContent(
'I am not writing the article. The example is long enough as is ;).'
);
$feed->addEntry($entry);
/**
* Render the resulting feed to Atom 1.0 and assign to $out.
* You can substitute "atom" with "rss" to generate an RSS 2.0 feed.
*/
$out = $feed->export('atom');
```
The output rendered should be as follows:
```xml
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title type="text">Paddy's Blog</title>
<subtitle type="text">Writing about PC Games since 176 BC.</subtitle>
<updated>2009-12-14T20:28:18+00:00</updated>
<generator uri="http://framework.zend.com" version="1.10.0alpha">
Zend\Feed\Writer
</generator>
<link rel="alternate" type="text/html" href="http://www.example.com"/>
<link rel="self" type="application/atom+xml"
href="http://www.example.com/atom"/>
<id>http://www.example.com</id>
<author>
<name>Paddy</name>
<email>paddy@example.com</email>
<uri>http://www.example.com</uri>
</author>
<link rel="hub" href="http://pubsubhubbub.appspot.com/"/>
<entry>
<title type="html"><![CDATA[All Your Base Are Belong To
Us]]></title>
<summary type="html">
<![CDATA[Exposing the difficultly of porting games to
English.]]>
</summary>
<published>2009-12-14T20:28:18+00:00</published>
<updated>2009-12-14T20:28:18+00:00</updated>
<link rel="alternate" type="text/html"
href="http://www.example.com/all-your-base-are-belong-to-us"/>
<id>http://www.example.com/all-your-base-are-belong-to-us</id>
<author>
<name>Paddy</name>
<email>paddy@example.com</email>
<uri>http://www.example.com</uri>
</author>
<content type="html">
<![CDATA[I am not writing the article.
The example is long enough as is ;).]]>
</content>
</entry>
</feed>
```
This is a perfectly valid Atom 1.0 example. It should be noted that omitting an
obligatory point of data, such as a title, will trigger an exception when
rendering as Atom 1.0. This will differ for RSS 2.0, since a title may be
omitted so long as a description is present. This gives rise to exceptions that
differ between the two standards depending on the renderer in use. By design,
`Zend\Feed\Writer` will not render an invalid feed for either standard
unless the end-user deliberately elects to ignore all exceptions. This built in
safeguard was added to ensure users without in-depth knowledge of the relevant
specifications have a bit less to worry about.
## Setting Feed Data Points
Before you can render a feed, you must first setup the data necessary for the
feed being rendered. This utilises a simple setter style API, which doubles as
a method for validating the data being set. By design, the API closely matches
that for `Zend\Feed\Reader` to avoid undue confusion and uncertainty.
`Zend\Feed\Writer` offers this API via its data container classes
`Zend\Feed\Writer\Feed` and `Zend\Feed\Writer\Entry` (not to mention the Atom
2.0 specific and extension classes). These classes merely store all feed data in
a type-agnostic manner, meaning you may reuse any data container with any
renderer without requiring additional work. Both classes are also amenable to
extensions, meaning that an extension may define its own container classes which
are registered to the base container classes as extensions, and are checked when
any method call triggers the base container's `__call()` method, allowing method
overloading to the extension classes.
Here's a summary of the Core API for Feeds. You should note it comprises not
only the basic RSS and Atom standards, but also accounts for a number of
included extensions bundled with `Zend\Feed\Writer`. The naming of these
extension sourced methods remain fairly generic; all extension methods operate
at the same level as the Core API, though we do allow you to retrieve any
specific extension object separately if required.
The Feed API for data is contained in `Zend\Feed\Writer\Feed`. In addition to the API
detailed below, the class also implements the `Countable` and `Iterator` interfaces.
### Feed API Methods
Method | Description
------ | -----------
`setId()` | Set a unique identifier associated with this feed. For Atom 1.0 this is an `atom:id` element, whereas for RSS 2.0 it is added as a `guid` element. These are optional so long as a link is added; i.e. if no identifier is provided, the link is used.
`setTitle()` | Set the title of the feed.
`setDescription()` | Set the text description of the feed.
`setLink()` | Set a URI to the HTML website containing the same or similar information as this feed (i.e. if the feed is from a blog, it should provide the blog's URI where the HTML version of the entries can be read).
`setFeedLinks()` | Add a link to an XML feed, whether it is to the feed being generated, or an alternate URI pointing to the same feed but in a different format. At a minimum, it is recommended to include a link to the feed being generated so it has an identifiable final URI allowing a client to track its location changes without necessitating constant redirects. The parameter is an array of arrays, where each sub-array contains the keys "type" and "uri". The type should be one of "atom", "rss", or "rdf".
`addAuthors()` | Sets the data for authors. The parameter is an array of array,s where each sub-array may contain the keys "name", "email", and "uri". The "uri" value is only applicable for Atom feeds, since RSS contains no facility to show it. For RSS 2.0, rendering will create two elements: an author element containing the email reference with the name in brackets, and a Dublin Core creator element only containing the name.
`addAuthor()` | Sets the data for a single author following the same array format as described above for a single sub-array.
`setDateCreated()` | Sets the date on which this feed was created. Generally only applicable to Atom, where it represents the date the resource described by an Atom 1.0 document was created. The expected parameter may be a UNIX timestamp or a `DateTime` object.
`setDateModified()` | Sets the date on which this feed was last modified. The expected parameter may be a UNIX timestamp or a `DateTime` object.
`setLastBuildDate()` | Sets the date on which this feed was last build. The expected parameter may be a UNIX timestamp or a `DateTime` object. This will only be rendered for RSS 2.0 feeds, and is automatically rendered as the current date by default when not explicitly set.
`setLanguage()` | Sets the language of the feed. This will be omitted unless set.
`setGenerator()` | Allows the setting of a generator. The parameter should be an array containing the keys "name", "version", and "uri". If omitted a default generator will be added referencing `Zend\Feed\Writer`, the current zend-version version, and the Framework's URI.
`setCopyright()` | Sets a copyright notice associated with the feed.
`addHubs()` | Accepts an array of Pubsubhubbub Hub Endpoints to be rendered in the feed as Atom links so that PuSH Subscribers may subscribe to your feed. Note that you must implement a Pubsubhubbub Publisher in order for real-time updates to be enabled. A Publisher may be implemented using `Zend\Feed\Pubsubhubbub\Publisher`. The method `addHub()` allows adding a single hub at a time.
`addCategories()` | Accepts an array of categories for rendering, where each element is itself an array whose possible keys include "term", "label", and "scheme". The "term" is a typically a category name suitable for inclusion in a URI. The "label" may be a human readable category name supporting special characters (it is HTML encoded during rendering) and is a required key. The "scheme" (called the domain in RSS) is optional, but must be a valid URI. The method `addCategory()` allows adding a single category at a time.
`setImage()` | Accepts an array of image metadata for an RSS image or Atom logo. Atom 1.0 only requires a URI. RSS 2.0 requires a URI, HTML link, and an image title. RSS 2.0 optionally may send a width, height, and image description. To provide these, use an array argument with the following keys: "uri", "link", "title", "description", "height", and "width". The RSS 2.0 HTML link should point to the feed source's HTML page.
`createEntry()` | Returns a new instance of `Zend\Feed\Writer\Entry`. This is the Entry data container. New entries are not automatically assigned to the current feed, so you must explicitly call `addEntry()` to add the entry for rendering.
`addEntry()` | Adds an instance of `Zend\Feed\Writer\Entry` to the current feed container for rendering.
`createTombstone()` | Returns a new instance of `Zend\Feed\Writer\Deleted`. This is the Atom 2.0 Tombstone data container. New entries are not automatically assigned to the current feed, so you must explicitly call `addTombstone()` to add the deleted entry for rendering.
`addTombstone()` | Adds an instance of `Zend\Feed\Writer\Deleted` to the current feed container for rendering.
`removeEntry()` | Accepts a parameter indicating an array index of the entry to remove from the feed.
`export()` | Exports the entire data hierarchy to an XML feed. The method has two parameters. The first is the feed type, one of "atom" or "rss". The second is an optional boolean to set indicating whether or not Exceptions are thrown. The default is `TRUE`.
> #### Retrieval methods
>
> In addition to the setters listed above, `Feed` instances also provide
> matching getters to retrieve data from the `Feed` data container. For
> example, `setImage()` is matched with a `getImage()` method.
## Setting Entry Data Points
Below is a summary of the Core API for entries and items. You should note that
it covers not only the basic RSS and Atom standards, but also a number of
included extensions bundled with `Zend\Feed\Writer`. The naming of these
extension sourced methods remain fairly generic; all extension methods operate
at the same level as the Core API, though we do allow you to retrieve any
specific extension object separately if required.
The Entry *API* for data is contained in `Zend\Feed\Writer\Entry`.
### Entry API Methods
Method | Description
------ | -----------
`setId()` | Set a unique identifier associated with this entry. For Atom 1.0 this is an `atom:id` element, whereas for RSS 2.0 it is added as a `guid` element. These are optional so long as a link is added; i.e. if no identifier is provided, the link is used.
`setTitle()` | Set the title of the entry.
`setDescription()` | Set the text description of the entry.
`setContent()` | Set the content of the entry.
`setLink()` | Set a URI to the HTML website containing the same or similar information as this entry (i.e. if the feed is from a blog, it should provide the blog article's URI where the HTML version of the entry can be read).
`setFeedLinks()` | Add a link to an XML feed, whether it is to the feed being generated, or an alternate URI pointing to the same feed but in a different format. At a minimum, it is recommended to include a link to the feed being generated so it has an identifiable final URI allowing a client to track its location changes without necessitating constant redirects. The parameter is an array of arrays, where each sub-array contains the keys "type" and "uri". The type should be one of "atom", "rss", or "rdf". If a type is omitted, it defaults to the type used when rendering the feed.
`addAuthors()` | Sets the data for authors. The parameter is an array of array,s where each sub-array may contain the keys "name", "email", and "uri". The "uri" value is only applicable for Atom feeds, since RSS contains no facility to show it. For RSS 2.0, rendering will create two elements: an author element containing the email reference with the name in brackets, and a Dublin Core creator element only containing the name.
`addAuthor()` | Sets the data for a single author following the same format as described above for a single sub-array.
`setDateCreated()` | Sets the date on which this entry was created. Generally only applicable to Atom where it represents the date the resource described by an Atom 1.0 document was created. The expected parameter may be a UNIX timestamp or a `DateTime` object. If omitted, the date used will be the current date and time.
`setDateModified()` | Sets the date on which this entry was last modified. The expected parameter may be a UNIX timestamp or a `DateTime` object. If omitted, the date used will be the current date and time.
`setCopyright()` | Sets a copyright notice associated with the entry.
`addCategories()` | Accepts an array of categories for rendering, where each element is itself an array whose possible keys include "term", "label", and "scheme". The "term" is a typically a category name suitable for inclusion in a URI. The "label" may be a human readable category name supporting special characters (it is encoded during rendering) and is a required key. The "scheme" (called the domain in RSS) is optional but must be a valid URI.
`addCategory()` | Sets the data for a single category following the same format as described above for a single sub-array.
`setCommentCount()` | Sets the number of comments associated with this entry. Rendering differs between RSS and Atom 2.0 depending on the element or attribute needed.
`setCommentLink()` | Sets a link to an HTML page containing comments associated with this entry.
`setCommentFeedLink()` | Sets a link to an XML feed containing comments associated with this entry. The parameter is an array containing the keys "uri" and "type", where the type is one of "rdf", "rss", or "atom".
`setCommentFeedLinks()` | Same as `setCommentFeedLink()`, except it accepts an array of arrays, where each subarray contains the expected parameters of `setCommentFeedLink()`.
`setEncoding()` | Sets the encoding of entry text. This will default to UTF-8, which is the preferred encoding.
> #### Retrieval methods
>
> In addition to the setters listed above, `Entry` instances also provide
> matching getters to retrieve data from the `Entry` data container. For
> example, `setContent()` is matched with a `getContent()` method.
## Extensions
- TODO