I had to make a RSS channel on my current project and didn’t want to include any third party scripts that didn’t have the advantages of Yii. This is why I created this Extension.
Please refer to this post for bug reports and/or suggestions.
If you want to generate nested(?) tags, I found a bug in the EFeedItemAtom.php code that overwrites the existing tag… uh… let me show you, I’m too tired to explain:
$item->addTag(‘georss:where’,array(‘gml:Point’=>‘test’)); <- I do this
and for the code to work I had to patch the getElement function
private function getElement( EFeedTag $tag ){
$element = '';
if(in_array($tag->name,$this->CDATAEncoded))
{
$tag->attributes['type']="html";
$element .= CHtml::openTag($tag->name,$tag->attributes);
$element .= '<![CDATA['.PHP_EOL;
}else
{
$element .= CHtml::openTag($tag->name,$tag->attributes);
}
if(is_array($tag->content))
{
foreach ($tag->content as [color="#FF0000"]$tag[/color] => $content) [color="#00FF00"]//change this to $newtag, or you will overwrite your $tag[/color]
{
$tmpTag = new EFeedTag([color="#FF0000"]$tag[/color], $content);[color="#00FF00"]//same here.. change it to $newtag[/color]
$element .= $this->getElement( $tmpTag );
}
}
else
{
$element .= (in_array($tag->name, $this->CDATAEncoded))? $tag->content : CHtml::encode($tag->content);
}
//print_r($tag);die();
$element .= (in_array($tag->name, $this->CDATAEncoded))? "]]>":"";
$element .= CHtml::closeTag($tag->name).PHP_EOL;
return $element;
}
then I can produce Atom Code like this:
<georss:where>
<gml:Point>test</gml:Point>
</georss:where>
I just tested this with one level, but I’ve to make it deeper… we’ll see if it works out
I’m currently looking for an Extenions to produce an Atom feed and noticed a glitch in the implementation of the UUID function: The functions doe /not/ create a valid random UUID according to RFC4122.
4.4. Algorithms for Creating a UUID from Truly Random or
Pseudo-Random Numbers
The version 4 UUID is meant for generating UUIDs from truly-random or
pseudo-random numbers.
The algorithm is as follows:
o Set the two most significant bits (bits 6 and 7) of the
clock_seq_hi_and_reserved to zero and one, respectively.
o Set the four most significant bits (bits 12 through 15) of the
time_hi_and_version field to the 4-bit version number from
Section 4.1.3.
o Set all the other bits to randomly (or pseudo-randomly) chosen
values.
I see, so you talking about Version 4 of UUID and that’s correct:
Version 4 UUIDs use a scheme relying only on random numbers. This algorithm sets the version number as well as two reserved bits. All other bits are set using a random or pseudorandom data source. Version 4 UUIDs have the form xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx where x is any hexadecimal digit and y is one of 8, 9, A, or B. e.g. f47ac10b-58cc-4372-a567-0e02b2c3d479.
And another problem: I noticed that current version of EFeed passes an entry’s URL to EFeed::uuid() and EFeed::uudi() uses MD5($url) as base for the UUID. But (sorry, I am quite picky with these issues) then the UUID is not a random UUID.
You could use the URL "as is"
RFC 4287, 4.2.6
Using the URL of the feed / the entry is a valid option according to RFC4287 and in my eyes far better than pretending that the ID is something else.