-
Add a new module editview_demo and document it This module contains a sample view with all node fields. Not all of them are working yet, but they should be working in a (future) -rc1 release.
-
Add a list of supported Views fields and those that are still buggy. Added both to the README and in the Help text.
-
Fix for unfiltered taxnonomy view fields. If "limit field by vocabulary" was not selected, no vocabularies where shown.
-
Fix the editing of vocabulary terms (#460206, #172797, #347568). With this commit, vocabularies are actually working, even the free tagging ones. Note though that this may have broken Organic Group support (though I have the nagging suspicion that was broken anyway, see #586160). The current implementation honors the selection of taxonomies within the Taxonomy:All Terms views field. Only selected vocabulary will be editable. Of course, if you select vocabularies that are not in the node edit form (because they are not attached to this node type) you will not be able to edit them anyway. Only if more than one vocabulary is editable the name of the vocabulary is rendered.
-
Update Changelog to reflect all changes after beta2
-
Add the patch solving the disappearance of the delete confirmation with private downloads and locales to the module tree. This patch was already referenced in the README.txt.
-
Include a patch for CCK that will fix multiple-valued fields, especially as used for node references. See also CCK issue #1037460. Note that several of the solved bugs were submitted for Drupal 5.x or even older; as Drupal 6.x is now the oldest supported version and the issues are fixed in it, they have been marked fixed too. #635080: "Add another item" adds to wrong node #609644: Nodereference field not showing up in D6 #426322: Does this module work with node reference CCK fields #296744: Select list for parent does not show up in editview #296662: Buttons #264855: Doesn't seem to work with multi-reference nodes #98363: doesn't display nodereference fields for editing
-
More work on saving and restoring #id in edit forms with AJAX. Global variable $editview_within_js has been removed. Instead of setting it when entering editview_js, it is now dynamically detected by checking $_POST['HTTP_X_REQUESTED_WITH'] for the value XMLHttpRequest. This helps handling the case where AJAX is introducted by some other module. I hope this will work with non-Apache webservers and non-Firefox browsers. Move the restoring of #id values from editview_js to editview_form_after_build, again to make it work with other AJAX handlers. Remove the code which disabled the drag-and-drop on tables.
-
Proxy the editview_form_after_build function through the main module file. The editview.views.inc will not always be loaded.
-
In commit #410226 the code which was somewhat cryptically marked as "Rebuild form until element IDs match originals" was removed. This commit adds replacement code that is hopefully more robust. Drupal tries to make sure any HTML id's are truly unique by appending serial numbers to them to avoid clashes. These numbers are not remembered anywhere between page loads, though, and especially not when doing AJAX callbacks. That means that if an AJAX function returns HTML with id's, there is no guarantee these id's are not already used in a page. Most browsers do not really care and render pages with duplicate id's without much trouble - until some Javascript code tries to identify elements by their id's. Then all kinds of unexpected things happen. The new code in this commit remembers all id's used in a form within an editview. Regrettably, these unique id's are only generated at a very late stage of the handling of the form, and at that moment it is too hard to add this information directly to the form. Instead we save it through Drupal.settings and use Javascript to copy it to a hidden form element. Note that the whole issue of unique id's only matters when using Javascript AJAX callbacks, so this will do no harm if Javascript has been switched off. The id's are put into an array which is serialized, gzipped and finally base-64 encoded to keep it small. This is typically about 1.5 KB overhead for each displayed form.