I am trying to learn how to create a custom content type programmatically from within my module.
However, after uninstalling and reinstalling my module I was getting an error stating that one or more of the fields I was trying to create could not be created because they already exist.
So I went hacking through my databse, removing the content type and all tables that belonged to it.
Same result -- field already exists.
Next I went to the Drupal API website looking for ways to delete fields and field instances, and came across
field_delete_field()
and
field_delete_instance()
I made a php page to try to delete the fields that I had created, only to get an error stating that the table I was trying to delete does not exist.
So I'm kinda stuck -- I can't create the fields because they already exist, and I can't delete them because they don't exist!
BTW the code I was modeling my module after is the code found in the "node_example" section of the Drupal examples module.
Ouch, deleting the database tables manually is never a good idea - Drupal's not that forgiving :)
Just to address the code in your install/enable hook, wrap the field creation in:
if (!field_info_field('field_name')) {
field_create_field(...
}
That will stop the problem happening again. Or if you don't want to do that, make sure the field is deleted in the uninstall/disable hook. Obviously that method would potentially result in data loss.
To address the current problem, follow this process:
Completely uninstall (not just disable) your custom module. If it's in an inconsistent state, just delete its row in the system table.
Delete all traces of the field from the field_config and field_config_instance tables.
Truncate all the cache tables manually (any table beginning with cache_).
Not strictly necessary but clear up any lingering content:
$nids = db_query('SELECT nid FROM {node} WHERE type = :type', array(':type' => 'type'))->fetchCol();
node_delete_multiple($nids);
That ought to do it.
Any time you delete a field, through the UI or programatically you'll need to either run cron or call field_purge_batch() to 'hard' delete the fields as they're only marked for deletion in the first instance.
Related
Users modify a DB object in an edit form that I have, pretty straight forward.
I need to implement a 'change log' on this object. I need to record which fields where changed and what they were before and after. I'm using Razor MVC.
I've done this by writing triggers for the table on update/delete. On update/delete of a record, the trigger pushes the record to a History table, in a History database. This creates the change log. Then you would just need to display it; to identify the change would require evaluating each and every field.
There's nothing already built that wold do this for you that I know of.
Is it possible in Drupal to find out which user modified a particular field? Not just the whole node. After saving the content I want to display the author name next to that field.
Not sure if this is possible or not.
This is not provided by Drupal core, and (As far as I know) it is not provided by any contributed modules on drupal.org.
So, in order to do that, you would probably need to create a custom module.
A simple module to achieve that would have a database table with (nid, uid, current field value) and hook_node_presave implementation (compare field values, then update/insert/ignore saving new data to your database table).
I have encountered a "problem" (fussy client) with a WordPress site and I will be restoring it back to a downloaded .gz database from two months ago. Now, in my work since then, I'd installed a new theme and created custom post types. The new theme has a number of custom CSS settings, and the custom post types have a number of files.
Since I'm doing a database restore to a snapshot before the new theme and custom post types existed, I have a few questions:
-Will this restore all setting to how it was configured at the time (general, reading, discussion)?
-Will the plugins that were added later just be deactivated?
-I'm guessing the new theme will still exist since its files are physically there. Will any settings on the new theme get erased with the database restore or will they stay and the theme just gets deactivated?
It's a messed-up situation and I basically want to restore back to August but archive my work on the new theme and custom posts if possible. Thanks!
If you restore the Wordpress database, you will change all of your settings back to the way they were at the time of the backup. The reason for this is the wp_options likely contains your theme options and definitely contains most Wordpress settings menu options (permalinks, reading, etc).
The plugins that were added later will be deactivated - there is a record in wp_options called active_plugins which is an array of your active plugin. Overwriting this value will disable new plugins, but as long as they are in the /wp-content/plugins directory, you can re-activate them, albeit with their settings missing. The same goes for your theme - as long as the files are there you can re-activate, but the missing options values will mean the settings are gone.
Now for something for helpful. First, definitely make a backup of your site as it exists now before you do anything else. Once you have a backup, rather than dropping the tables, etc, you can try renaming this schema so that it won't conflict, and then restore your backup to a new schema that contains the original name (the one Wordpress is configured to use now). With two schemas on the same server, you can now run queries to compare the current database values and the restored database values as well as insert them where necessary. Assume your restored schema is called restored and your current schema is called current, the following cross scheme query would show you any settings that don't exist in the restored schema:
SELECT co.option_id, co.option_name, co.option_value, co.autoload
FROM current.wp_options co
WHERE co.option_id NOT IN
(SELECT ro.option_id FROM restored.wp_options ro)
Add in some WHERE co.option_name LIKE 'key_% type queries to extract certain sets of values if you wanted to copy them into your restored schema. You might want to take a look at the wp_postmeta values in a similar way, or even compare values from the wp_options table where the ID/key exists, but the values don't match to see what changed.
Good luck!
I am having some difficulties with my module I am currently working on. As part of this module I have created a few fields that appear on a form. This form is based in a custom entity.
First I am using field_create_field($field); to create the row in the field_config table. I am then using field_create_instance($instance); to create the row in the instance table and also create the table that begins with field_data_field.
The problem I am running into is how to remove these tables correctly at the end. I have tried manual deletion (via hook_uninstall), I've tried field_delete_field, I've tried to use the remove_instance hook that is built into the Commerce module. Either way, I end up getting lots of field_deleted_data_xxx tables being created. These don't even have data in them as I created a manual query to empty the main data tables before this function was called that seems to create these tables.
Has anyone else ever run into this problem? How do I stop Drupal from creating these tables??
You can't stop Drupal from creating them but I believe you can rid yourself of them totally using field_purge_batch and its related functions.
I really wish I knew the answer to your second question (in your comment above), my instinct would be that if you re-attach the field to the bundle then that data would become automatically available again (otherwise it really doesn't make sense to keep hold of the deleted tables) but I really can't be sure about that.
Is it possible to have a Rules Condition that a node has been updated more than once?
I need different email alerts for when content is created and when its updated. The issue is that im using the Multistep module:
http://drupal.org/project/multistep
The Multistep module breaks the node creation form into 2 or more separate pages. One the first page the node is created but unpublished. When you finish all the steps the node is updated and published. I need the email to be sent after the node has had all the steps filled in, as the CCK fields are used in the email. Therefore I cant use Rules inbuilt event of 'After saving new content' and 'After updating existing content'.
How can I differentiate in Rules from when the node is first fully filled in, and when its subsequently updated? One way to do this would be to have different conditions for weather the node has been updated once or more than once. Is this possible and if so, is it the best solution?
Thanks
I think the easiest way to do this would be too look at the URL or referrer like mentioned here, http://drupal.org/node/827728. You'd have to use the Execute PHP functionality and have some knowledge of how to write a short script though.
PROBLEM:
How to test for the number of times a node has been modified.
POSSIBLE SOLUTION:
Include a "counter" field in the CCK that is hidden from the user (via CSS) and auto-incremented each time the node is accessed. Then use the value of this counter in rules conditions.
(See e.g., http://drupal.org/node/1172550 for more details)
PROBLEM:
How to treat a node differently based on whether it is being 'added' for the first time, or 'updated'.
POSSIBLE SOLUTION:
Create a path rule that is conditional on node type.
Trigger the path rule for the node/add page of the specific node type.
Pre-populate fields on the node/add page using the elementdefaults module.