Opened 13 years ago
Closed 13 years ago
#17808 closed defect (bug) (invalid)
Using only custom post types results in 404 on RSS feeds
Reported by: | heilhard | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.1.3 |
Component: | Feeds | Keywords: | |
Focuses: | Cc: |
Description
I'm working on a site that only uses custom post types and as a result doesn't have any "real" posts. I created an RSS feed + rewrite rules for parts of the site and it works correctly but gives a 404 although the actual content is correct.
How to reproduce:
Remove all posts from a fresh WP install. Register a custom post type. Create a feed that has a query for that custom post type. Write a post in the custom post type. The resulting feed will show the custom post, but will come back with 404 status code. Adding a dummy post in the regular posts section will return the feed status to 200.
Attachments (2)
Change History (6)
@
13 years ago
This is the actual news feed. Rename it to news-feed.php and copy it into TEMPLATEPATH.
#2
@
13 years ago
- Keywords reporter-feedback removed
The two attached files work within the twentyten theme. In the given scenario I see this curl results:
# curl --head http://localhost/?feed=newsfeed HTTP/1.1 404 Not Found Date: Wed, 15 Jun 2011 10:09:56 GMT Server: Apache/2.2.17 (Unix) mod_fcgid/2.3.5 mod_ssl/2.2.17 OpenSSL/0.9.8l DAV/2 mod_wsgi/3.3 Python/2.7.1 PHP/5.3.4 X-Powered-By: PHP/5.3.4 X-Pingback: http://localhost/xmlrpc.php Last-Modified: Wed, 15 Jun 2011 10:09:56 GMT ETag: "94471d4c9f96266146e2b123cf0ff15f" Expires: Wed, 11 Jan 1984 05:00:00 GMT Cache-Control: no-cache, must-revalidate, max-age=0 Pragma: no-cache Content-Type: text/xml; charset=UTF-8
Hope this helps!
#3
@
13 years ago
Oh, this is the result without --head
# curl -v http://localhost/?feed=newsfeed * About to connect() to localhost port 80 (#0) * Trying 127.0.0.1... connected * Connected to localhost (127.0.0.1) port 80 (#0) > GET /?feed=newsfeed HTTP/1.1 > User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3 > Host: localhost > Accept: */* > < HTTP/1.1 404 Not Found < Date: Wed, 15 Jun 2011 10:19:22 GMT < Server: Apache/2.2.17 (Unix) mod_fcgid/2.3.5 mod_ssl/2.2.17 OpenSSL/0.9.8l DAV/2 mod_wsgi/3.3 Python/2.7.1 PHP/5.3.4 < X-Powered-By: PHP/5.3.4 < X-Pingback: http://localhost/xmlrpc.php < Last-Modified: Wed, 15 Jun 2011 10:19:22 GMT < ETag: "94471d4c9f96266146e2b123cf0ff15f" < Expires: Wed, 11 Jan 1984 05:00:00 GMT < Cache-Control: no-cache, must-revalidate, max-age=0 < Pragma: no-cache < Content-Length: 1274 < Content-Type: text/xml; charset=UTF-8 < <?xml version="1.0" encoding="UTF-8"?> <rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" > <channel> <title>wpdev » Page not found</title> <atom:link href="http://localhost/?feed=newsfeed" rel="self" type="application/rss+xml" /> <link>http://localhost</link> <description>Just another WordPress site</description> <lastBuildDate>Wed, 15 Jun 2011 10:08:16 +0000</lastBuildDate> <language>en</language> <sy:updatePeriod>daily</sy:updatePeriod> <sy:updateFrequency>1</sy:updateFrequency> <generator>http://wordpress.org/?v=3.1.3</generator> <item> <title>test</title> <link>http://localhost/?custom_news=test</link> <pubDate>Wed, 15 Jun 2011 10:08:16 +0000</pubDate> <dc:creator>admin</dc:creator> <guid isPermaLink="false">http://localhost/?post_type=custom_news&p=5</guid> <description><![CDATA[test]]></description> <content:encoded><![CDATA[<p>test</p> ]]></content:encoded> </item> </channel> </rss> * Connection #0 to host localhost left intact * Closing connection #0
#4
@
13 years ago
- Milestone Awaiting Review deleted
- Resolution set to invalid
- Status changed from new to closed
Looking at the output, I believe WordPress is doing as you're asking. In adding the rule yourself, what WordPress is doing on that page load, is querying for the home page, since there is nothing on the front page, it's 404'ing. The fact your custom files then output something is ignored as WordPress expects your themes 404 page is being served.
The flow for that iscurrently:
- Parse request, it's a index hit, it's not a feed (as it's not registered via add_feed())
- Query for Home page posts, Find none, throw a 404, let the themes 404 be served
- Theme kicks in, some code which calls create_newsfeed() is run (not included in your example)
- WP_Query call is made and a Query is made for the custom post type, It's not the main request, so headers are not set.
- Theme is output with the 404 from step 2, WordPress believes your serving a 404 page.
Quick suggestions:
- use your custom rules and Hook parse_request, and set your request there (instead of using new WP_Query
- use add_feed() and hook parse_request and set your request, hope it works..
- Use your code as is with double queries, and call status_header(200); in your custom newsfeed..
Either way, This isn't a core bug, it's a common fault of "Doing things too late" ie. after the WordPress queries have already run. If you need any further details, please use a support avenue such as the wp-hackers mailinglist or the Support forums.
Can you provide some code which duplicates the problem to make it easier for others to confirm and diagnose the issues?