MagpieRSS user-agent filter

[JohnLamansky]

Being able to customize the MagpieRSS user-agent would be useful for large WordPress sites (e.g. BuddyPress-powered social networks) who would want to identify themselves by their own site name instead of as "WordPress".

[JohnLamansky]

This patch would define the MAGPIE_USER_AGENT constant only if it hasn't already been defined. The constant could be defined through a manually-added constant definition in index.php, for example, or (preferably) via a plugin by hooking into the load_feed_engine action.

[JohnLamansky]

An alternate method, passing the user-agent through a filter instead of requiring a constant definition

[JohnLamansky]

I've attached two different ways of doing this; I'll leave it up to the head developers to decide which one's better.

[DD32]

Would be better to just consolidate all the external access functions so that the user agent for all requests can be managed.. (#4779)

[JohnLamansky]

Even if Magpie used a remote_http() function like you mention, one would have to manually change the rss.php code to add the desired user-agent as a parameter for all remote_http() calls. Therefore, a magpie_user_agent filter would be appropriate regardless of whether or not ticket 4479 is implemented.

[DD32]

Replying to JohnLamansky:

Even if Magpie used a remote_http() function like you mention, one would have to manually change the rss.php code to add the desired user-agent as a parameter for all remote_http() calls.

At the time, I was thinking of the Plugin adding itself to the User agent via a filter in the function for all requests. Not too sure how that'd work in retrospect though.

[JohnLamansky]

A much better method

[JohnLamansky]

Ignore the first two attachments; I think rss.php-3.diff offers the most flexibility.

[ryan]

Milestone 2.5.2 deleted

[westi]

(In [8503]) Allow a plugin to change the filter the magpie user agent string. Fixes #7085 props JohnLamansky.