No-op `MagpieRSS`

[desrosj]

MagpieRSS is an XML-based RSS parser built in the days of PHP 4.x.

MagpieRSS has been deprecated in WordPress since version 3.0 was released in 2010. The library itself has not been updated since 2004 and is abandoned.

Since then the library has continued to be included with WordPress to avoid breaking any sites that may have been using it. It has been deemed an "adopted" external library, but only the following very minor updates have been made:

• inline documentation.
• changes to avoid fatal PHP errors in modern versions of PHP.
• changes to avoid deprecated notices/other warnings in modern versions of PHP.

Looking at the plugin directory, there is ​almost no meaningful usage of the class. 90-95% of the matches are false positives related to identifying when a crawler is accessing pages/feeds.

Enough time has passed since deprecating this class where no-opping can be considered to avoid continuing to ship code that no one is using.

[desrosj]

Linking some additional history:

• #11982 handled deprecating MagpieRSS (committed in [12822]).
• WordPress Core was updated to use SimplePie instead of MagpieRSS in 2007 in #4547.

[anantajitjg]

Based on the ticket, #57102, I am also in favor of removing this from the core WordPress files. Since this is in core WordPress files, I have submitted the PR for the ticket #57102. Looking forward to more updates.

[ironprogrammer]

Related: #58337.

[Clorith]

I've done some filtering to remove the false positives from the original WPDir search, and add more missed entries I guess... seems to have done a good job of it, and gives a much clearer picture of actual usage: ​https://wpdirectory.net/search/01J3JJWDQK27PKB3E0ZPPY1Q93

The biggest concern I have is that Wordfence appears to use this file as the default when checking for path disclosures(?), other than that there are some plugins that have been closed (either by the authors them selves, or for other reasons, most notably security reasons it seems).

My main concern is that roughly 50% of them are using require statements (I've not looked at how many are closed when taking this number), so it would potentially cause fatal errors to anyone in those scenarios, unless we plan on retaining the file, and noop all the functions within it? Doing so would still keep a "dummy" file in the codebase though, which I feel we'd want to be able to clean up if we are to remove something that's been deprecated this long... (I also just opened #61743 as I think this is a place where we can be proactive in the future, perhaps giving that priority, and allowing one or two releases of it surfacing such deprecations, and then being able to remove these two files is an idea?!)

(work in progress)

Trac 57107

[sabernhardt]

Argh. I had intended to create that PR on my fork for someone else to continue building on that (if desired). The classes would still need work, and that was about as far as I could take it.

I think keeping the file(s) would be good, though the contents probably could be reduced/removed.

[desrosj]

The file has been throwing a deprecated warning since WordPress 3.0. That seems like a reasonable time frame. I believe that my thinking when I originally created this ticket was to leave the file with the class inside but no-opped.