Viewfields reset to none after updating when Views name + display name > 32 characters (field_attached_view_vname too short)

I just updated my to 6.x-1.x-dev (2009-Mar-27) and saw all the viewfield-fields were not displaying. I decided to place back the old (dev-version) viewfield module and it worked again. It's a good thing I always first back-up the whole site (and database) before updating modules...

I find this curious as I tested this against multiple sites with different viewfield configurations and did not have any issues such as this. I'm wondering which version you're currently using. Can you post a tarball of the copy you're using on your site currently?

Jer

+1 to this. It happened the same thing to me.
I´ve used the last dev 6.x version. Now it only appears the last one the one updated to march 27.
But the older one (one that isn´t appearing in the releases list) worked ok.

Can you provide the requested information? I need to confirm the code you're using which works to verify what the problem might be. I have a good guess, and I'm working to account for it right now.

Jer

This is what I´ve been using. (Attached). Thanks for your help!

That's helpful, thanks for the info.

What versions of Drupal Core and CCK are you using on this site? Can you take some screenshots of your viewfield configuration on both the content type and node level?

Thanks!

Jer

I´m using Drupal 6.10, and same CCK version as Junro.

More details about the problem:
- When you enter an override default option in the definition and select OVERRIDE DEFAULT in the submitting form, it does not work.
- When you do not enter an override deafult in definition, the default value is set to 'none' in the creation time and re-reset to 'none' when you edit the node (no matter how view was selected). The arguments are respected.

Probably it is a problem in the way default values are treated. It seems that the default value override the current value. When you edit a node all is reset to something unpredictable. But the viewfields with force default works fine.
For me is a big problem because I have a lot of nodes which works with the older versions .
I am using the last version (27-3)

I re-installed 2009-feb-20 version and after deactivating and re-activating the module thinghs works as expected, i.e.:

- OVERRIDEN fields maintain the overriding view
- NOT overrrided fields maintain the default view.

More information: 2009-mar-2 version respected the selected view but changed it when editing, i.e. you have to manually change the view each time the node was edited. The override default option did not work at all (i had to deactivate it)
I hope this information will be useful.

My site runs Drupal 6.10; CCK 6.x-2.2; Viewfield 6.x-1.x-dev (03/27). Fields configured as shown in the two attached screenshots are no more output. Those fields use forced default values. I have to mention, that, unlike for the 5.x viewfield version, I was obliged to check the "Use a common default value ..." during the port of my site from D5 to D6, in order to have the "forced default value" option working correctly. I hope that will help ....

Thanks for your work.
Regards.

Not sure if this is related to this issue, if it is not, please let me know and I'll submit another one.

I have a content type named "Page with view" and had the same problem with "disappearing" views from viewfields. After re-entering them manually I realized that most nodes have their views back but some of them still have them set as "none" and this cannot be changed (edit a node -> select a view for the viewfield -> save the node -> no view is displayed -> edit the node again -> viewfield is set to "none" -> unable to do anything with it).

I realized that the problem lies in the content_type_page_with_view table. The field_view_vname column in this table can hold a varchar(32), which is the maximum allowed length of a view identifier. But this column contains not just the view identifier but also an appended "|default" string (at least in my case). So, if the view identifier is longer than 24 characters, the total length of the string is higher than 32 and the string is truncated (only e.g. "trips_in_the_czech_republic|defa") is saved into the table.

By extending the column to hold a varchar(48) I was able to temporarily solve the problem on my site (dirty and nasty hack, I know).

Hope this is somehow helpful...

For now, I´ve changed up my version from latest dev, and replaced it from the oldest one posted in #8, which seems to work. (It works for me at least :).

These are the known cases for disappearing viewfield views:

• Previewing a node with a viewfield (fixed in 3/27 snapshot)
• Updating a node with a viewfield when content field permissions prevented the user from accessing the viewfield (fixed in 3/27 snapshot)
• Updating a node's status from admin/content/node (fixed in 3/27 snapshot)
• Having a view name (with display name) greater than 32 characters
• Moving from 8/27/08 D6 snapshot or D5 to 02/10/09 snapshot or greater

The last 2 issues have not been fixed yet. The field length issue is straight forward and will be fixed shortly. The last issue is a bit trickier. In the 02/10/09 snapshot I added support to select individual displays in Views 2. This meant that you could drill into your view and pick a specific display rather than having to create a new default display for each viewfield. When this was implemented, an upgrade path was not added. Up until the 3/27 snapshot, the default display was generally still used - so the issue went somewhat un-noticed. With the changes in 3/27 that corrected the first 3 issues listed above, this behavior went away and all old viewfields that hand not been updated to select a display stopped working.

In the next snapshot of Viewfield I'll add the upgrade hook which will go back and select the default display for existing viewfields if a display is not already selected. This will require a run of update.php to execute.

If anyone has found any other issues with vanishing views that I have not listed above, please let me know so I can investigate further.

Thanks!

Jer

Fixed in CVS commit 193572. The fix will be applied when you run update.php.

Did you run update.php?

A similar problem was encountered on a Drupal site I maintain after upgrading to Views 2.5, i.e. viewfields on existing nodes were no longer displayed in the node output.

I found that editing the node (not actually making any changes) and saving it would fix the problem. This proved to be a feasible solution on this particular site as there were only a small number of nodes with viewfields.

In hindsight, perhaps this would have been remedied by clearing Drupal's cache tables...?

I tried clearing the cache from the Performance section and it didn't work. I also tried the editing and saving method but the viewfields still don't show up. This is all with the latest dev version of viewfield, the latest stable version of Views (2.5) and the latest stable CCK (2.2).

*edit* nearly forgot: Drupal version 6.11, although 6.10 had the same problem...

Duplicate issue 460900.

The cause of this issue is that for Views 1 we used the display format to choose a Views display style plugin. In Views 2, some of those plugins no longer exist, so there is no matching display format. As a result, the viewfield is not displayed.

We now use the view selection list to choose the display. I will write an update to map the old display formats to displays. In the mean time, saving both field settings and the display settings for your content type should cause it to display, unless you are experiencing the problem described in issue 434920.

Fixed in CVS commit 215694.

I can confirm that the latest dev verson works without a problem for me. No more views disappearing...

I can confirm it doesn't work. Actually, the other time it happened I was able to restore it by bulk saving nodes. Now I've done all that and the view just doesn't show up in the nodes. I'm confused.

Alright, I take it back. It also seems I was suffering from #434920: Arguments not saved or passed.. It should be working now.

This seems to still be an issue and should be re-opened.

I am Using:

• Viewsfield 6.x-1.x-dev
• Views 6.x-2.6
• Content Construction Kit (CCK) 6.x-2.5

Problem: When going into the node edit form, the viewsfield cck reset to none.

Solution:View Names ( machine -readable) over 26 characters seem to trigger this problem,

I have views with names clocking in at 21 and 25 characters in length, and they're suffering from this issue as well.

The *vname field is a varchar set to the length 32. This is the also max for Views name so at first glance it should work well.

The *vname field however stores not simply the name of the view, it stores "[name]|[display]". When that combination gets to more than 32 characters the bug is triggered.

My solution is to increase the length to 127.

The biggest part of the patch is the update function that fixes this for all existing fields instances.

P.S. It may look like I rewrote the whole viewfield.install but that because it used to have Windows line breaks and I changes it to standard Unix.

The patch in #37 have now been tested by a customer and was pushed out to production this morning. Seems to be working as it should, including the update function.

The patch in #37 is now running in production on three different customers sites. No problems so far.

I can also confirm that #37 fixed my problems with viewfield not displaying properly. I did have to change all the names in the database manually.

Sorry, #37 no longer applies, so I'm unable to figure out the actual changes.

I've fixed the character encoding + line endings of all files in the meantime.

Updated my patch against HEAD. Thanks for taking a look at it!

+++ viewfield.install	24 Aug 2010 17:51:35 -0000
@@ -78,3 +78,34 @@ function viewfield_update_6000() {
+  $result = db_query("SELECT * FROM {content_node_field} WHERE type = 'viewfield'");
+  while ($field = db_fetch_array($result)) {
+    $field_result = db_query("SELECT * FROM {content_node_field_instance} WHERE field_name = '%s'", $field['field_name']);

Hm. Is there a reason for why we have to query everything on our own? Updates in content.install happily use CCK API functions content_fields() and content_database_info().

+++ viewfield.install	24 Aug 2010 17:51:35 -0000
@@ -78,3 +78,34 @@ function viewfield_update_6000() {
\ No newline at end of file

This should not happen.

+++ viewfield.module	24 Aug 2010 17:51:36 -0000
@@ -68,7 +68,7 @@ function viewfield_field_settings($op, $
-        'vname' => array('type' => 'varchar', 'not null' => FALSE, 'length' => 32),
+        'vname' => array('type' => 'varchar', 'not null' => FALSE, 'length' => 127),
         'vargs' => array('type' => 'varchar', 'not null' => FALSE, 'length' => 255),

The number 127 needs to be explained in an inline comment above 'vname' line. Why exactly 127 and not 255 or 128?

Powered by Dreditor.

I copied most of viewfield_update_6001() from viewfield_update_6000() as I assumed it follow best practice. I also saw some mention in content.install not to use content_fields() but now that I look more closely it only applies to hook_install(). Do you want me to rewrite the update function using content_fields() etc.?

The view name can be 32 characters and the display name 64, 32+64 = 96. (2^n)-1 then gives 127.

CCK seems to use that formula as well, but we could as well make it 128 as many other modules do.

Ideally yes, please. Also, I suck at maths (and so do other readers), so I'm not sure why it's not 96, but 127, i.e., requires an inline comment.

Duplicate issue at #1096718: field_attached_view_vname too short.
See also #942986: Viewfield Override Defaults does not remain ticked after resaving.

I don't suppose someone is actually going to fix this?

I'll fix it if I get access: #1105646: Applying to be co-maintainer of the Viewfield module.

Fabulous.

Updated #43 to make viewfield_update_6001() use more of the content API. Please review and test.

http://drupalcode.org/project/viewfield.git/commit/9c1a16c

+++ b/CHANGELOG.txt
@@ -11,6 +11,7 @@ Viewfield 6.x-1.x, xxxx-xx-xx
+Issue #416922 by frjo, keithm: Fixed vname too short.

1) The changelog is reverse chronological. New entries are added to the top.

2) No "Issue" prefix in the changelog, please. Only required for the commit message (in git).

+++ b/viewfield.install
@@ -77,3 +77,40 @@ function viewfield_update_6000() {
+/**
+ * Implements hook_update_N()
+ * Update vname fields to varchar(128).
+ * @see viewfield_field_settings()
+ */
+function viewfield_update_6001() {

1) phpDoc of update functions should be the summary only; no "Implements ..."

2) There should be a blank phpDoc line between the summary and any other phpDoc description or directive. Please read http://drupal.org/node/1354 for details.

+++ b/viewfield.install
@@ -77,3 +77,40 @@ function viewfield_update_6000() {
+      db_change_field($ret, $table_name, $vname_info['column'], $vname_info['column'],
+        array(
+          'type' => 'varchar',
...
+        )
+      );

The "array(" should be part of the db_change_field() line; likewise, the closing parenthesis of the two stacked together on the same line ());), consequently decreasing the indent of the inner array keys.

Powered by Dreditor.

CHANGELOG.txt
1) Changed.
2) Changed, though http://drupal.org/node/52287 shows changelog entries that include 'Issue' and emphasizes re-using commit messages. Does http://drupal.org/node/52287 need to be updated? Related to this, this document describes longer changelog entries having a blank line between the main entry and 'more description' but I don't see any examples of this in other modules. Is http://drupal.org/node/52287 correct in calling for this blank line in the changelog and commit message?

viewfield.install
1) Changed.
2) Changed.

Patch attached, using newer naming convention than #51 :-/ Up until a couple days ago, http://drupal.org/node/1054616 used to read

git diff origin/[version] > [issue-number]-[description]-[comment-number].patch

+++ b/CHANGELOG.txt
@@ -4,15 +4,15 @@ Viewfield x.x-x.x, xxxx-xx-xx
+#1052370 by Anclywen: Fix unrestricted list of allowed views.

s/Fix/Fixed/ - can be adjusted prior to commit.

Thanks! I'll take care of the handbook page.

http://drupalcode.org/project/viewfield.git/commit/69374de

+++ b/viewfield.install
@@ -77,3 +77,40 @@ function viewfield_update_6000() {
+    $update = db_query("UPDATE {" . content_field_tablename() . "} SET db_columns = '%s' WHERE field_name = '%s'", $db_columns, $field['field_name']);
+    $ret[] = array('success' => $update !== FALSE, 'query' => "UPDATE {" . content_field_tablename() . "} SET db_columns = '$db_columns' WHERE field_name = '$field[field_name]'");

Why isn't this (and a later added update query) not using update_sql()?

Powered by Dreditor.

update_6000() was written a long time ago, before my time, so I'm not sure. I wrote update_6001() (later renamed as update_6003()) patterned after update_6000() before I knew about update_sql(). I used update_sql() in later updates such as update_6004(). Do you recommend going back and changing the ones that aren't using update_sql()?

Yeah, ideally we use update_sql(). It should only not be used when selecting/preparing data for an update, or when a single module update would potentially lead to hundreds of individual update queries being logged to the update.php screen.

Keith, remember that there are still 754 D5 users left. When they upgrade, they will go through all the available updates.

Patch attached.

+++ b/viewfield.install
@@ -111,8 +111,8 @@ function viewfield_update_6003() {
       $db_columns = serialize($field['db_columns']);
...
+      $sql = sprintf("UPDATE {" . content_field_tablename() . "} SET db_columns = '%s' WHERE field_name = '%s'", $db_columns, $field['field_name']);
+      $ret[] = update_sql($sql);

OUCH. Ok, I forgot to mention that serialized values are the only other exception, which actually disallows use of update_sql(), since the SQL string is handed over to db_query(), and db_query() stupidly tries to perform database table escaping on all {values}.

Blindly assuming that this applies to both update_sql()s in that update, reverting issue status.

Sorry for the noise (and wasting your valuable time). :-/

Powered by Dreditor.