#241030 by csevb10 - drupal_get_path in .install incompatible with installation from an install profile.

#214490 - followup - we don't really *have* to provide alpha-to-alpha update functions, but it's probably best anyway...

#207839 Missed removing one of the hook_requirements that is no longer needed now that we use hook_last_update.

Also, since we now know we cannot assume the content module update has run before a field module will need the fields info, revert back to an earlier version of content_install_types() that will work even if the node_fields table has not been updated.

#207839 Missed removing one of the hook_requirements that is no longer needed now that we use hook_last_update.

#208576 D6 runs all updates of any module in the modules folder, whether or not it is installed, and whether or not the content module is installed. Adding if(module_exists) tests to all of them for now pending further investigation.

#198508 Working on fixes to problems created when some but not all field modules are enabled on an update. I've added an 'active' column to the field tables and altered all the queries so they filter for only active fields. That got rid of numerous errors on the update and also fixed a problem where inactive fields were still showing up on the Manage Fields and Display Fields screens.

I set up the active field to default to zero, then update it when field modules are updated, so, hopefully, inactive fields will just disappear everywhere.

We'll need to watch this to be sure it doesn't introduce other problems.

- rename content_install_types() to content_types_install()
- add missing include in content_storage_type() - was OK
  since the function is always called from content_crud.inc
  currently...
- remove unnecessary (array) casts

#198508 Clean up update process to accomodate the possibility that some field modules won't get enabled until later while still making sure the module and column fields of the fields tables get populated as soon as we have any information about them. Fix those we can in content module's update, fix others using hook_content_notify when they get enabled, add special fixes needed for optionwidgets and text which changed the widget names so they don't update automatically.

There are still more complex upgrade issues to address, just getting this much of the fix committed.Patch by fractile81 and me.

 well.

Make sure content version variable is up to date. Change handling for cache tablename and db_table_exists() testing in _content_type_info() to avoid numerous  db queries caused by all those calls of db_table_exists().

Remove old updates that spanned several schema changes and require that database be current before upgrading to 6.x. This is needed because the CCK database has dramatically changed several times, including changing to and then away from table names that were later usurped by core. The 6.x structure finishes moving completely away from using table names prefixed with 'node_' to avoid future upgrade problems as core incorporates more parts of CCK.

This means 4.7 to 6.x upgrades will require an intermediate update to 5.x, and 5.x to 6.x upgrades will require that the latest code be used to upgrade the database in 5.x before upgrading to 6.x.

This won't be popular, but maintaining all those old updates to make sure that nothing breaks no matter what state the database is in has become an impossible task. Hopefully once everyone is stablized using the 6.x structure we can stick to automatic updates in the future.

Lots of cleanup of the new batch schema alter function, including making sure it will run correctly when called from an .install update function.

Clean up old content.install functions to consolidate several that did similar things that created and then fixed some problems into a single new function that will clean up the database in all cases.

This is probably going to break things again, but we now deprecate content_alter_db_table() and introduce content_alter_schema() which first analyzes the changes to see if they will result in loss of data, then uses batch processing to update the nodes one at a time, and then finally do the actual change to the schema.

#191833 when first installed, the last part of the schema cannot be created because the content_field and content_field_instance tables aren't created yet. Need to pass the $schema back without proceeding if that is the case.

Create a helper function for the cache tablename since it gets changed, this will help avoid errors during updates prior to the new table creation. Changed names of content_field and content_field_instance tablename helper functions and made them public, since they are used by other modules.

#97861 change schema to store field column and module info in the field settings table so we have a way to clean fields up after a field module is uninstalled and rework all code to retrieve that info from the database instead of using module_invoke('database columns').

#157176 major restructuring to move most existing field crud processing to content_crud.inc. This still needs more testing and is not the final API, but it is a beginning.

Switch to using _content_field_tablename() and _content_field_instance_tablename() instead of node_field or content_field to properly handle tablenames before and after name change. Needed so update functions and their calls to content functions will work properly whether or not the tables have been renamed.

Now that we are renaming node_field_instance to content_field_instance, make sure no tablename clashes can happen if a field named 'field_instance' already exists.

Rename node_field, node_field_instance, node_group, and node_group_fields to prefix them with 'content' instead of 'node'.

Add module that creates fields and widgets to the node_field and node_field_instance tables. Needed this to have a way to delete fields since field  info, including the module that created it, is no longer available once the module has been disabled.

Make sure schema gets refreshed when field types change! More changes to remove use of #field in elements and replace it with new #field_info value in $form; Move install, uninstall, enable, and disable hooks all into .install file; Start developer upgrade documentation.

#157176 First round of FAPIzing the widgets. Widget invoke hook_elements() and use FAPI #process, #value_callback, etc. Widgets now only produce a single element and content module handles multiple values. Widget elements are designed to be agnostic about where they are placed. The content module places them on nodes, but it should be possible to write custom code to place them elsewhere by creating a $field array that will tell the widget what parameters to use. See the referenced issue for more details.