I created a view that works just fine. I then exported it and started playing with a few of it's properties.
I changed the machine name for the display (display_id) so that it's more easily referenced by me, a non-machine.
<?php
$handler = $view->new_display('block', 'Sans author', 'sans_author');
?>So, it looks to work just fine but in reality it doesn't quite.
I will go to the theme information and scan for files and it will find the files just fine. I can even save with no apparent errors.
The issue, though, is that it doesn't actually save the file(s) it scanned for previously. I would rescan these and save again but the issue is that it doesn't actually save.
Is there something that we can do or is there an issue here that cannot be fixed and I need to go back to the old machine names of block_1, block_2, block_3 etc?
Thank you,
A.Villanueva
Comments
Is this Views 3?
Is this Views 3?
6.x-2.8 actually. The issue
6.x-2.8 actually.
The issue isn't even this anymore. It's more complex and frustrating. The server is on 5.2.9 and whenever I rescan for template files it won't find it. So I'm not sure if this is a views specific thing or something else.
pounding head on desk
Hi, did you empty your views
Hi, did you empty your views cache? Do you use firebug? Then you can see where your theme files are.
Greetings, Martijn
how did you change the
how did you change the machine name! that doesn't work in Views2
@Summit yes I emptied the
@Summit yes I emptied the view cache and yes I use firebug :=)
@Scott Reynolds You can change the machine name when you export and change it manually but it's not going to work. When you save your views after scanning for templates it'll revert back to the defaults.
So I gave up on this for now and wait for views 3 when it is ready.
The other issue btw was completely my own. I was in the wrong template. The templates that we have up there are old and named very similarly so you can easily make mistakes. Views is on 6.x.2.8 now and everything is working on the staging server. Hopefully the production server will take to the changes as well. That one I'm worried about.
Thanks,
A.Villanueva
Right thats the point, you
Right thats the point, you can't do this in Views2. Just because you can change the text in a file doesn't mean the code will work.
I don't want anyone to stumble on this post and think its possible in Views2. It just plain isn't.
You won't be able to do this
You won't be able to do this in Views 3, either. The 'machine names' in Views are just that. Machine names. They cannot have spaces. They follow the same rules as the view name, and other similar concepts in Drupal such as node type names.
@merlinofchaos It sucks that
@merlinofchaos It sucks that you can't change the display_id because when you have a view folder hierarchy and you have some display a meaningful name is mch more useful to me than having an auto generated id. For instance block_with_no_author means more, and thusly more meaningful to me than block_1.
I am okay with not using custom display_ids in views 2 but in v3 (acronym pun) it would be great to be able to customize them. At least views should take the display name and format it properly and then we can use that.
Ciao,
A.VillanuveA
You might be misusing
You might be misusing displays. You should probably be using the view name to provide meaning, not the display id.
That said, in Views 3 the display ID is changeable, just not to something "Human readable".
BTW as I reread this, I suspect the issue has nothing to do with your changing the display ID. Views does not actually do the rescanning of the template files, nor does it save it. That is completely Drupal core. Other people have experienced issues, particularly when using admin.module (though other people have tried this with admin module and have not had this happen so that may not be related), that later rebuilds of the theme registry do not catch these templates. I have never been able to duplicate this to investigate it, so I have no idea why.