Closed (won't fix)
Project:
Views (for Drupal 7)
Version:
6.x-2.12
Component:
page displays
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
10 Jun 2011 at 20:25 UTC
Updated:
25 Aug 2017 at 11:01 UTC
Jump to comment: Most recent
Comments
Comment #1
merlinofchaos commentedDouble check that you do not have a url alias / path alias stealing the path and pointing it somewhere else?
Comment #2
jsheffers commentedActually now that I look.. When I look in the aliases in the backend of Drupal it's not there. It's in the Database though...
Comment #3
merlinofchaos commentedCheck the path module UI for the specific path. Or change the path you're trying to use to something you're certain cannot match an alias already in the system.
Comment #4
jsheffers commentedOh that's not the issue. It's an obscure path already, I've tried 2-3 obscure paths to no avail. Which I know are not being used.
Comment #5
merlinofchaos commentedStrange. There is something wrong with your system; that feature works and a quarter million sites have Views on it and it's a very, very small number of them that aren't using page displays with paths. It's hard to guess what might be wrong in your system that would be interfering, though.
Comment #6
jsheffers commentedSo what would recommend trying next? Creating a block view from the same view works correctly, and this issue hasn't always been present..
Comment #7
josetpnet commentedI am working in my computer with XAMPP and PHP 5.2.14 and there is no problem with my views.
If I export exactly the same data and upload drupal modules to my hosting (PHP version 5.3.8) I get 404 error with only 1 of 4 views. More over, the offending view works as expected with wrong parameters, but it shows 404 errors with right parameters (wich is just a taxonomy term).
Everything works fine if I use my computer connected to my hosting database: I get the right results for the offending view.
Comment #8
merlinofchaos commentedThis isn't a crash bug, it is clearly not critical.
It would suggest that the data is different, and your 'right' data is somehow not validating in the arguments properly. My guess would be an argument is forcing the view to 404 because of validation fail.
Comment #9
josetpnet commentedIt's very important as far as I get 14 'Page not found error's in the main menu pages of my site, which are mostly based in View pages of the offending View. But you are right, isn't a critical issue. Sorry.
I am exporting and importing data with phpMyAdmin, so I guess they are exactly the same data.
I am switching my computer 'settings.php' between my local database and my hosting database, and there is no problem at all with the View (PHP 5.2.14). Everything works smooth, both with right or wrong parameters. The only parameter is a Term name, and the "Action to take if argument does not validate" is "Summary, sorted ascending".
But when use the hosting site, I get those 14 'Page not found error's. If I use de admin menu to edit the View, usually I get a javascript pop-up with the text "An error ocurred at /admin/build/views/ajax/preview/Carta. Error Description: 404: Not Found", except when the argument isn't a Term name of the taxonomy, where I get a list of terms with the count of ocurrences (as configured in "Summary, sorted ascending").
Comment #10
merlinofchaos commentedIf the same view works on one install but not the other, it really does seem as though the problem is going to be with the data, not the view.
Doublecheck that the cache was cleared and menu rebuilt after you put your export into place. Since you know what argument is failing to validate, though, I would recommend exploring your data and to ensure that the data you see is correct.
Comment #11
josetpnet commentedYou can reproduce this View '404 page not found Error" with PHP 5.3.8 and one View this way:
1. Include an image in "Fields" to output.
2. Set Format to "Hover: ... TO: ...".
3. Check "Link this field to it's node".
As soon as I unchecked the option "Link this field to it's node" View Pages started to work.
Comment #12
kenheim commentedI had a similar experience. I have an ubercart site that has been functioning fine for several months. I have a few different views in place (a Banner, using views slideshow; a table, presenting recent orders; and another table, presenting products in the catalog) These have all worked fine until I updated PHP to 5.3.8 to meet PCI compliance requirements. The catalog view suddenly started giving me 404 errors. It is the only view of the three that includes an image field with a link to node format option selected. The slideshow uses images that don't link, and it continued to work fine. When I removed the image field from the catalog view, the view began working normally again. Then I went and added the image back to the view, and the view continued to work normally. For me the link to node format option was not a factor after I removed and then added back the image field.
I'm running Drupal 6.22 and Views 6.x-2.16.
Comment #13
kenheim commentedChanging this from Support Request to a Bug Report.
Comment #14
El Bandito commentedSame here with Drupal.6.2 and Views 6.x-2.16 and a recent upgrade by my host to PHP 5.3. When I unchecked "Link this field to its node" on an image field the View started working again.
Comment #15
mustanggb commented