Jump to:
| Project: | Views |
| Version: | 7.x-3.x-dev |
| Component: | Wizard |
| Category: | bug report |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | postponed (maintainer needs more info) |
Issue Summary
I know that this is a similar error to some that have already been reported (e.g. #1232438: /blog path with arguments works in Views UI but gives Page Not Found Error when visited on site), but those were for D6, and this is to show that it’s still happening with D7 (very latest -dev release of 2012-Jan-02).
Here’s an Export of the View in question (which the client created, and is very upset that she cannot use):
$view = new view;
$view->name = 'upcoming_events';
$view->description = '';
$view->tag = 'default';
$view->base_table = 'node';
$view->human_name = 'Upcoming Events';
$view->core = 7;
$view->api_version = '3.0';
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */
/* Display: Master */
$handler = $view->new_display('default', 'Master', 'default');
$handler->display->display_options['title'] = 'Upcoming Events';
$handler->display->display_options['access']['type'] = 'perm';
$handler->display->display_options['cache']['type'] = 'none';
$handler->display->display_options['query']['type'] = 'views_query';
$handler->display->display_options['query']['options']['query_comment'] = FALSE;
$handler->display->display_options['exposed_form']['type'] = 'basic';
$handler->display->display_options['pager']['type'] = 'full';
$handler->display->display_options['pager']['options']['items_per_page'] = '10';
$handler->display->display_options['style_plugin'] = 'default';
$handler->display->display_options['row_plugin'] = 'fields';
/* Field: Content: Title */
$handler->display->display_options['fields']['title']['id'] = 'title';
$handler->display->display_options['fields']['title']['table'] = 'node';
$handler->display->display_options['fields']['title']['field'] = 'title';
$handler->display->display_options['fields']['title']['label'] = '';
$handler->display->display_options['fields']['title']['alter']['alter_text'] = 0;
$handler->display->display_options['fields']['title']['alter']['make_link'] = 0;
$handler->display->display_options['fields']['title']['alter']['absolute'] = 0;
$handler->display->display_options['fields']['title']['alter']['word_boundary'] = 0;
$handler->display->display_options['fields']['title']['alter']['ellipsis'] = 0;
$handler->display->display_options['fields']['title']['alter']['strip_tags'] = 0;
$handler->display->display_options['fields']['title']['alter']['trim'] = 0;
$handler->display->display_options['fields']['title']['alter']['html'] = 0;
$handler->display->display_options['fields']['title']['hide_empty'] = 0;
$handler->display->display_options['fields']['title']['empty_zero'] = 0;
$handler->display->display_options['fields']['title']['link_to_node'] = 1;
/* Sort criterion: Content: Post date */
$handler->display->display_options['sorts']['created']['id'] = 'created';
$handler->display->display_options['sorts']['created']['table'] = 'node';
$handler->display->display_options['sorts']['created']['field'] = 'created';
/* Sort criterion: Content: Type */
$handler->display->display_options['sorts']['type']['id'] = 'type';
$handler->display->display_options['sorts']['type']['table'] = 'node';
$handler->display->display_options['sorts']['type']['field'] = 'type';
/* Sort criterion: Content: When - start date (field_date) */
$handler->display->display_options['sorts']['field_date_value']['id'] = 'field_date_value';
$handler->display->display_options['sorts']['field_date_value']['table'] = 'field_data_field_date';
$handler->display->display_options['sorts']['field_date_value']['field'] = 'field_date_value';
/* Filter criterion: Content: Published */
$handler->display->display_options['filters']['status']['id'] = 'status';
$handler->display->display_options['filters']['status']['table'] = 'node';
$handler->display->display_options['filters']['status']['field'] = 'status';
$handler->display->display_options['filters']['status']['value'] = 1;
$handler->display->display_options['filters']['status']['group'] = 0;
$handler->display->display_options['filters']['status']['expose']['operator'] = FALSE;
/* Filter criterion: Content: Type */
$handler->display->display_options['filters']['type']['id'] = 'type';
$handler->display->display_options['filters']['type']['table'] = 'node';
$handler->display->display_options['filters']['type']['field'] = 'type';
$handler->display->display_options['filters']['type']['value'] = array(
'event' => 'event',
);
/* Filter criterion: Content: When - start date (field_date) */
$handler->display->display_options['filters']['field_date_value']['id'] = 'field_date_value';
$handler->display->display_options['filters']['field_date_value']['table'] = 'field_data_field_date';
$handler->display->display_options['filters']['field_date_value']['field'] = 'field_date_value';
$handler->display->display_options['filters']['field_date_value']['operator'] = '>=';
/* Display: Page */
$handler = $view->new_display('page', 'Page', 'page');
$handler->display->display_options['path'] = 'upcoming-events';
$handler->display->display_options['menu']['type'] = 'normal';
$handler->display->display_options['menu']['title'] = 'Upcoming Events';I also tried Exporting this View, then Disabling it, then Importing it as a new View (changing its name to append “2” to distinguish it from the Disabled original), and this time I get a rather alarming error message every time I attempt to Save the newly Imported View:
“The website encountered an unexpected error. Please try again later.”
Refreshing that page regenerates the error. Summoning the page again using the URL in the browser’s Address Bar brings back the Views UI, but with asterisks and the warning box indicating unsaved changes!
Of course, I did all the usual troubleshooting: upgraded to latest -dev release of this as well as Calendar and Date modules (the “Page Not Found” happened in the previous releases of all three as well), updating the database structure (both done via DruSh), clearing all caches (ditto), etc., to no avail. I even upped the memory limit for PHP.
Comments
#1
Maybe you should enable displaying php errors.
#2
Thanks, dereine. I checked the Logs instead (rather than enabling full error reporting on-screen on a production site), and found this when I tried to re-save the new View:
PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'upcoming_events_2' for key 'name': INSERT INTO {views_view} (name, description, tag, base_table, human_name, core) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5); Array ( [:db_insert_placeholder_0] => upcoming_events_2 [:db_insert_placeholder_1] => [:db_insert_placeholder_2] => default [:db_insert_placeholder_3] => node [:db_insert_placeholder_4] => Upcoming Events 2 [:db_insert_placeholder_5] => 7 ) in views_db_object->save_row() (line 2029 of {censored}/sites/all/modules/views/includes/view.inc).Seems it saved it after all, but then tried to save it again for some reason, resulting in the Duplicate Key error.
When I went back to the List of Views, I saw that the new View had indeed been created. I tried to go to the Page Path, and got the same “Page Not Found” error I had been getting before. This time, I checked the Error logs, and found two new entries, both of type PHP (shown in the order they occurred):
Does this help? Looked to me like it may have to do with the menu entry that the View Page was supposed to go in: the client tried to put it in the Navigation Menu instead of the Main Menu, and we have the Navigation Menu hidden. But changing it to “No Menu” didn’t fix it.
#3
Thanks that's helping a lot.
You probably have to open the views_view and views_display table and remove the entries and start from scratch.
#4
Okay, I didn’t delete the old view (didn’t want to destroy the client’s work), but I did Add a whole brand-spanking-new Content-type View from scratch, and had the Add View Wizard create the Page Display, and it, too, displays “Page Not Found” when I click “View Page” from the Views UI.
Another wrinkle: when I went to Save it, it did as before and refreshed the page, but when it refreshed, it still had the yellow warning banner at the top saying “* All changes are stored temporarily. Click Save to make your changes permanent. Click Cancel to discard the view.”, and the Master and Page Display tabs still had asterisks (“*”) on them indicating unsaved changes. Clicking [Save] a second time gave the Unexpected Error message (complete with Log entry similar to before, with the Duplicate Key).
When I went back to the Views List, the new View was there, so I clicked its [Edit] button. Without doing anything else, the View UI appeared just as it did before, complete with the same Unsaved Changes warning banner and asterisks! Yes, including saying “Click Cancel to discard the view.” instead of something like, “Click Cancel to discard your changes.”
When I clicked [Save] again, an AJAX Error dialog popped up and went away too fast for me to copy-paste from (I remember it saying “Error #4” or some such). Then the “Unexpected error” message appeared.
One thing that may be related: these Views are involving the Event content type created by the Date module’s Date Tools wizard that creates Event Calendars. Also in the logs I’ve been seeing a lot of errors apparently involving the Date module, including (all of these have “Location: …/admin/structure/views/view/uc_test/preview/page/ajax” and “Referrer: …/admin/structure/views/view/uc_test/edit/page”, and all happened within the same minute, and repeat enough times to make me believe that the entire group of errors is happening once for every data row):
I’ll create an Issue in the Date queue about this, also.
#5
Okay, I just updated to the newest 2012-01-05 (there were at least two on that date!) release of Views (the one I just did invoked a database update “#7301 — Enlarge the name column”). Same problems.
I tried creating a new View on another Node type that has no Date field(s), in case the problem had to do with the many problems that have cropped up in the latest Date -dev release (including about ½ a dozen PHP errors in the log per invocation of the Date module for any reason).
Again, the “unexpected error.” Again, a similar PDOException in the Log, but this time not accompanied by any php errors from the Date module:
PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'places_test' for key 'name': INSERT INTO {views_view} (name, description, tag, base_table, human_name, core) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5); Array ( [:db_insert_placeholder_0] => places_test [:db_insert_placeholder_1] => [:db_insert_placeholder_2] => default [:db_insert_placeholder_3] => node [:db_insert_placeholder_4] => places-test [:db_insert_placeholder_5] => 7 ) in views_db_object->save_row() (line 1966 of …/sites/all/modules/views/includes/view.inc).What is going on here!?
#6
Okay, now this is weird! I just updated everything (CTools, Dates, Views, and some others) to new -dev releases as of 2012-Jan-10, then went in to delete the test View I made in #5 and recreate it to see if the problems have been resolved or at least mitigated.
Lo and behold:
B-b-but, I’m logged in as User 1! And I checked that Administrator Role has full Views Admin access! Why wouldn’t it let me Delete a View!?
So, I went to Disable it instead of Delete it. I got this:
Something is seriously wrong here. Is my whole installation corrupt or what!?
At any rate, I decided to instead create a new test View from scratch, and append a “_2” on its Machine Name and “-2” on its Human name, and just used the Wizard to generate the View with a Page Display. This time, I told it to [Save and Exit], instead of [Save and Continue]. The Page Display works fine!
Apparently, when we do [Save and Continue], the new View is created, but the UI is opened in such a way that it thinks that the View is still brand-spanking-new, never been saved. So, when the user goes to save it, it does an INSERT INTO instead of an UPDATE into the database table(s), thus causing the PDOException above and the strange appearances of the Unsaved Changes banner.
Workaround for Now
Never do [Save and Continue] when using the Add View Wizard. Always do [Save and Exit], then call the View List back up and Edit the View if you wish to customize it further.
Proposed Fix
Change the action of the Add View Wizard’s [Save and Continue] button so that it opens the UI as if it were Editing an Existing View (which it apparently is), not Creating a New one (the “Save” process of “Save and Continue” has apparently already done that).
I’ll do some more tests to verify this hypothesis.
#7
Changed this Issue’s Component since the actual cause of the error seems to be happening in the Add View Wizard instead of Page Displays (that being merely a symptom — the View was never being fully Saved in usable form).
#8
Apparently, when we do [Save and Continue], the new View is created, but the UI is opened in such a way that it thinks that the View is still brand-spanking-new, never been saved.It's continue and edit not save and continue. I think you see the difference :) That's the intended behavior from my perspective,
but i still have no idea what happend to the views in your database.
maybe make a backup and try to remove the broken entries in views_view/views_display manually via sql.
#9
You’re right, it is [Continue and Edit]. Should’ve looked again. But, what exactly does that do? Since it goes to a new page entirely, and since HTTP is an inherently stateless protocol, it must store the temporary View-in-progress somehow, somewhere, so that it can be retrieved. Surely it doesn’t stash the entire View into a temporary cookie? Nor is it in QueryString ($_GET[]). HTTP PUT data? Session variables?
Or is it storing it in the database, but in an unfinished form? That seems more likely, without my examining the PHP code itself.
#10
Also, keep in mind that it does this to brand new Views, not just the presumably corrupted one I originally posted about. If I create an entirely new View from scratch (using the Wizard, which appears to be the only way to do it now in D7-3.x) and click [Continue and Edit], it, too, will fail to save correctly.
#11
It's stored in ctools_object_cache which stores information in the ctools_object_cache table
Is it broken for all kind of view-names or just for some special ones?
#12
I'm getting similar behavior with my views paths. When I create a new view with the wizard, the path works. If I try to change the path for a display, and save the view, then I get the "Page not found" error. SOMETIMES, if I open the view again, open the path to edit it, but then just apply and save again without changing anything, it works. SOMETIMES, however, it doesn't matter how many times I change the path, no matter how many places in menus and blocks it recognizes the changed path, I still get "Page not found" when I go to the path directly.
So, I'm not sure whether it's not really saving or just what. But I have caching for the site turned off, and even if I clear caches, I get the same behavior.
#13
Sorry. I had an alias conflict. Working now.
#14
Ok I am having the same problem but I cant't fix it what should I do. When I create a new view and I click on "Save and exit", I get a white page when I refresh the page, the view is created but when I click on the link it shows me the following:
Page not found
The requested page "/node/dmusic" could not be found.
Thanks in advance
Damiaan
#15
white pagehttp://drupal.org/node/158043 gives you a lot of information what you actually should do in that case. Once you have done it you will see some kind of error message.
#16
#17
I am having this problem with 7.x-3.3. When I tried to delete the view I get this error returned:
Notice: Undefined property: view::$export_type in ctools_export_ui->access() (line 128 of /home/steve/drupal/drupal7/sites/all/modules/ctools/plugins/export_ui/ctools_export_ui.class.php).Along with an access denied for user 1, which makes sense for access($op, $item).
Disabling the view returns:
An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /admin/structure/views/view/who_we_are/disable?token=XbtIBzEjX_1ltPJruPh2NjhS2Igk9FSXokYg-WoaklQ
StatusText: Internal Server Error
ResponseText:
#18
#19
In general needs review means that there is a patch, which is not ...
Always read http://drupal.org/node/158043 and provide all possible information. Especially the latest error should actually be caused by another php error. Could you please have a look at this document and report them? This would probably really help.
Regarding the first error this seems to happen if you save a view, which already exists. Here are some examples, but there may be more.
#1335658: Problem with views integration
#1437266: Can't delete nor modify/save a view
Maybe also #1527778: View::save needs to check for machine name before saving. Not reliant on vid only. helps you for this issue.
#20
Thanks for your tips, none of these seem to directly address the "Page not found" issue when attempting to view a new view "page" - do they? Maybe this could be one the general problems associated with vid, but I can't tell. This issue is quite serious for me and I am willing to help resolve it any way that I can. I have been using Views for several years without anything like this occuring, I'm not sure where to begin in order to provide the community with helpful feedback, but I do think that this issue should remain open.
#21
So ... please read my first link :)
It's maybe hard to see but often this kind of issues can be solved immediately if some information is given.
So about the error message. I guess you had the problem of #1527778: View::save needs to check for machine name before saving. Not reliant on vid only. which caused the view not to save as expected. Once you have a broken view in the database something like deleting/disabling via the ui can be broken as well. Maybe you could make a backup and then remove the database entries from views_view, which points to that view.
#22
I was actually referring to your first link about vid, but I don't think that it addresses the issue I'm having, which can be easily summarized thusly: When I create a new view with a page view, save it and then try to view the page, I get a page not found error. I can use drush or other methods to delete these views and try again, but the problem is persisting with every new view I create. However, I think that in light of this persistence, that the problem is probably not with views, but with with the directory permissions on my site.