Now, entry title is optionnal and may be found in h3 HTML element.
Entry content is mandatory and may be found in div[class="item-content"] HTML element.
Moreover, the title may contain simple quotes (here, encoded) so the bridge have to decode first to apply format library function. In case we don't do that, the format function double encode the quote and something like ' could appear.
* [VkBridge] Convert special HTML entities to characters in pageName
* [VkBridge] Generate feed item title
* [VkBridge] Remove double backslashes in feed item link
* [VkBridge] Unpin post if pinned
* [VkBridge] Mark reposted messages
* [VkBridge] Correct external link parsing
* [VkBridge] Added article parsing
* [VkBridge] Added video parsing
* [VkBridge] Added photo parsing
* [VkBridge] Added album link parsing
* [VkBridge] Added one more external link selector
* [VkBridge] Using array of link selectors to remove
* [VkBridge] Added document parsing
* [VkBridge] Added sign parsing
* [VkBridge] Fixed incorrect sorting with pinned item
* [VkBridge] More methods to parse documents
* [VkBridge] Save fallback if page name element not found
* [VkBridge] Using post signed as feed item author
* [VkBridge] Fixed document link
* [VkBridge] Coding policy fixes
NotAlways right found it necessary to remove their RSS feeds recently. This is a *simple* bridge to grab the ones on the front page. It allows you to filter the articles based on their classification (right, working, romantic, related, learning, friendly, hopeless, unfiltered, or all).
The limit was used to specify the number of pages to return from a given
topic which resulted in the number of returned items variing between one
and however many entries are listed on one page.
This commit changes the implementation for the limit to keep loading more
pages until the specified limit is reached. Excessive elements are removed
in order to return the exact amount of items specified by the limit.
This behavior is closer to how other bridges are implemented and makes it
more natural to use without being too confusing. Existing queries must be
updated to account for the new limit.
References #657
cURL is a powerful library specifically designed to connect to many
different types of servers with different types of protocols. For
more detailed information refer to the PHP cURL manual:
- http://php.net/manual/en/book.curl.php
Due to this change some parameters for the getContents function were
necessary (also applies to getSimpleHTMLDOM and getSimpleHTMLDOMCached):
> $use_include_path removed
This parameter has never been used and doesn't even make sense in
this context; If set to true file_get_contents would also search
for files in the include_path (specified in php.ini).
> $context replaced by $header and $opts
The $context parameter allowed for customization of the request in
order to change how file_get_contents would acquire the data (i.e.
using POST instead of GET, sending custom header, etc...)
cURL also provides facilities to specify custom headers and change
how it communicates to severs. cURL, however, is much more advanced.
- $header is an optional parameter (empty by default). It receives
an array of strings to send in the HTTP request header.
See 'CURLOPT_HTTPHEADER':
"An array of HTTP header fields to set, in the format
array('Content-type: text/plain', 'Content-length: 100')"
- php.net/manual/en/function.curl-setopt.php
- $opts is an optional parameter (empty by default). It receives
an array of options, where each option is a key-value-pair of
a cURL option (CURLOPT_*) and it's associated parameter. This
parameter accepts any of the CURLOPT_* settings.
Example (sending POST instead of GET):
$opts = array(
CURLOPT_POST => 1,
CURLOPT_POSTFIELDS => '&action=none'
);
$html = getContents($url, array(), $opts);
Refer to the cURL setopt manual for more information:
- php.net/manual/en/function.curl-setopt.php
> $offset and $maxlen removed
These options were supported by file_get_contents, but there doesn't
seem to be an equivalent in cURL. Since no caller uses them they are
safe to remove.
Compressed data / Encoding
By using cURL instead of file_get_contents RSS-Bridge no longer has
to handle compressed data manually.
See 'CURLOPT_ENCODING':
"[...] Supported encodings are "identity", "deflate", and "gzip".
If an empty string, "", is set, a header containing all supported
encoding types is sent."
- http://php.net/manual/en/function.curl-setopt.php
Notice: By default all encoding types are accepted (""). This can
be changed by setting a custom option via $opts.
Example:
$opts = array(CURLOPT_ENCODING => 'gzip');
$html = getContents($url, array(), $opts);
Proxy
The proxy implementation should still work, but there doesn't seem
to be an equivalent for 'request_fulluri = true'. To my understanding
this isn't an issue because cURL knows how to handle proxy communication.
Requesting a username with a leading slash would cause error 500
because the requested URI would contain two slashes in a row.
For example username "/test" would result in:
https://facebook.com//test
References #628
