I've just done this on a view:

- I started editing it and got a validation error that there was no content type set on the node type filter. (Not sure why; maybe the content type got removed?)
- As I edited this filter, I thought, 'hang on, that shouldn't be defaulted, that should be specific to display A on this view'.
- I tried to save the view and can't, because while display A is now ok and validates, the default display still has missing data.

However, I don't see how I can get to this data to fix the problem, hence I can't save the view and my settings are lost.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

rdmillner’s picture

I had a similar issue since updating. I solved this problem by going to the field that was giving the issue on a display that I knew would validate and changing "Configure filter criterion for:" and changing it to all displays. Then I went back and made sure the other displays were overriding that to show what they needed to and this solved the problem.

merlinofchaos’s picture

Ugh. That's a case where you need to go into the Settings and check the box that makes the master (formerly default) display always appear.

In my opinion, anyone who actually uses Views a lot should do this regardless. The master display is a very important piece of information.

DjebbZ’s picture

I would have said the same thing than merlinofchaos. Go in the Settings and make the master display always appear.

dawehner’s picture

The patch from http://drupal.org/node/1343888#comment-5267556 would at least allow to access the default display directly via url.

joachim’s picture

> check the box that makes the master (formerly default) display always appear

Would there be any way to detect this sort of situation, and if the master display is hidden, tell the user to go enable it? I didn't know this option existed :)

> In my opinion, anyone who actually uses Views a lot should do this regardless.

Agreed!

dawehner’s picture

One suggestion:

* Make the default tab available via url
* When the validation fails on a display always show this display and mark the background of the tab as red.

This would allow people to fix the error, some oppinions?

dawehner’s picture

Priority: Critical » Major

Let's mark it as major as there is a temporary workaround and people can use views though.
Sure this should be fixed.

dawehner’s picture

FileSize
2.72 KB
4.92 KB

Okay here is a first approach, some critics are welcomed, the current code does add foo all the time to test it.

Maybe someone could come up with better colors.
There is also a color needed for opened tab has errors.

joachim’s picture

Status: Active » Needs review
FileSize
2.9 KB

The patch seems to cause the master display to be visible at all times, even with the setting turned off.

Here's an updated version of the patch with some tweaks to comments & a title attribute added to the tab so you get hover text.

> +.views-displays .secondary a.error {

If this is just for the tab, would using #views-display-menu-tabs be better?

joachim’s picture

Status: Needs review » Needs work

Sorry, it's still needs work because of the master display thing...

dawehner’s picture

The patch seems to cause the master display to be visible at all times, even with the setting turned off.

Yeah there was a reason it was set to active ...

If this is just for the tab, would using #views-display-menu-tabs be better?

Well the other css use the same selector

Do you agree in general with the approach?

joachim’s picture

What I mean is that the master display shows even if I comment out the 'foo' error, on any view.

> Well the other css use the same selector

Do you mean other things use the new red colouring, or other things use #views-display-menu-tabs?

Yes, the approach in general seems fine -- if the master display fails validation, show it, and highlight it as being the source of the problem.

alberto56’s picture

See #1419978: Allow saving of a view when there are validation errors on the master display (comment 4) for steps to reproduce a recoverable validation error in this context.

dawehner’s picture

+++ b/includes/view.incundefined
@@ -1889,9 +1897,13 @@ class view extends views_db_object {
+    $this->display_errors['default'] = TRUE;

Just wondering, maybe you overlooked this debugging line?

dawehner’s picture

Version: 7.x-3.0-rc3 » 7.x-3.x-dev
Status: Needs work » Needs review
FileSize
2.39 KB

So remove the debugging and update status.

dawehner’s picture

This patch definitive needs a review by someone else.

damiankloip’s picture

The patch works as it should; the logic is fine and classes are added to the markup correctly. I think it's just the css that is the problem :) As meantioned in IRC, I think it should be a red outline and not a background color. How about this?

dawehner’s picture

Version: 7.x-3.x-dev » 8.x-3.x-dev
Status: Needs review » Patch (to be ported)

Let's get it in

Thanks for the visual improvement and testing!

damiankloip’s picture

Status: Patch (to be ported) » Needs review
FileSize
2.51 KB

Here is one for 8.x

aspilicious’s picture

Status: Needs review » Reviewed & tested by the community

They look identical!

dawehner’s picture

Status: Reviewed & tested by the community » Fixed

Let's get it in!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.