Naturalrush
Forum Replies Created
-
I did not get it resolved.
Thanks Ben, I didn’t realize that exposed as an option up there. I hardly ever look at the screen options menu.
Okay, see image link below for what I’m seeing after updating a document.
http://dl.dropbox.com/u/4679701/screencaps/screenshot.854.pngI’ve uploaded a revision and the Revision Summary is checked so it should be displayed?
-Ray
Ben, thanks for the pointer of where to check in wp-document-revisions.php.
For the particular file I was testing with, I get the string as shown below with mixed slashes. Note that I am testing this on a WAMP setup. This is no good.
C:\xampp\htdocs\parkway/wp-content\uploads/4d1dd0c48d811ee913f6370de0481c08.pdfI can fix this with str_replace, but then validate_file fails on line 584. Checking the documentation I could find on this (below), it automatically fails on Windows systems with a result of 2.
http://phpdoc.ww.wp.xz.cn/trunk/WordPress/_wp-includes—functions.php.htmlSo, away goes validate_file on line 584, leaving only is_file to check things, and add a str_replace for consistent slashes before I hit that.
It works.
Thanks,
-RayBen or anyone else, I’m trying to get this plugin to work. After not getting anywhere I let it sit and here I go giving it another shot with the new 1.1 version. I’m getting the same thing, a 500 internal server error. In WP there is a 404 error (WP generated, not Apache) displayed. What I have noticed is there is a 301 redirect then the 500 error. Is the trailing slash supposed to be there? Below is are the line from the Apache log with a blank line put between them.
192.168.146.1 - - [24/Oct/2011:21:52:46 -0400] "GET /parkway/documents/2011/10/another-doc.pdf HTTP/1.1" 301 - "http://rushr-lt/parkway/wp-admin/post.php?post=391&action=edit&message=1" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1" 192.168.146.1 - - [24/Oct/2011:21:52:46 -0400] "GET /parkway/documents/2011/10/another-doc.pdf/ HTTP/1.1" 500 1165 "http://rushr-lt/parkway/wp-admin/post.php?post=391&action=edit&message=1" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1"No PHP errors show up. Any suggestions are welcome.
I’ll clarify the specific case a bit.
I was using a custom post type created by the WP Publication Archive plugin. http://ww.wp.xz.cn/extend/plugins/wp-publication-archive/
I haven’t tried it with any other custom post types. What I do know is setting the security for it has no effect–setting a post to be viewed only by a specific group. A user not in that group could see it. However this does work on built-in page/post types.
-Ray
This is an unusually quiet Friday night. So, with this gnawing at me I decided to look at it again. Good grief, I don’t know how I missed it. The URL isn’t valid. It is missing a slash so it’s http:/www.server.com instead of http://. Argh! Using an HTTP inspector it’s passing it fine. In fact, I was surprised to see it wasn’t properly url encoded. It appears this is an area where not all web servers behave the same. Apache allowed it but IIS 6 botched it without error.
One possible fix is line 92 of lib/class.publication-markup.php, the $uri var can be wrapped in urlencode(), so
return $downloadroot . urlencode($uri)-Ray
Follow up.
Error logging some output values, the path and filename look good.
The URI passed in on the $fPath var in openfile.php is valid, and logged into the site I can put that URI in the brower address and download the file. Path is valid. PHP can read and write it since it was uploaded in the first place.
I even tried commenting out the output buffering and using straight cURL with the same results.
Sigh
Screen should show up below this.
screenshot.823The exact code being used is
[wp-publication-archive categories="Agency Meeting Notes"]I did find a work around.
In line 256 of class.wp-publication-archive.php, where there is
if (wp_count_posts( 'publication')->publish > 10) {
using this instead appears to give the correct behavior
if ( count($publications) > 10) {Thanks,
-RayBen, thanks for getting back to me so quick.
WP is 3.2.1.
The document uploaded fine and saw the file with the hashed filename added to the uploads folder.
It was that weird 404 with the gray page.
I’ve worked in depth with WP before but it’s not that frequent. I think I followed all the instructions for setup and use. One thing I noticed about the doc URL was a trailing slash after the filename. Seemed a bit odd but maybe that’s how it works.
-Ray
I second this!
Thanks,
-Ray
