Installing CustomFields

By Arvind Satyanarayan on August 27, 2007 | Filed under CustomFields | Comments (26)

To install CustomFields, follow the steps below:

Download and extract the .zip or .tar.gz preserving the directories. These extracted directories correspond to directories of the same name in your Movable Type installation. Upload these files and directories to your Movable Type installation, your final file structure should look something like this (where mt-static is your StaticWebPath):

   MT_DIR/
   |__ mt-static/
   |   \__ plugins/
   |       \__ CustomFields/
   |           \__ images/
   |              |__ author.gif
   |              |__ category.gif
   |              |__ entry.gif
   |              |__ star.gif
   \__ plugins/
        \__ CustomFields/
           |__ customfields.pl
           |__ lib/
           |   |__ CustomFields/
           |      |__ App/
           |      |  |__ CMS.pm
           |      |  |__ Search.pm
           |      |__ BaseObject.pm
           |      |__ Field.pm
           |      |
           |      |__ Template/
           |      |  |__ ContextHandlers.pm
           |      |
           |      |__ Upgrade.pm
           |      |__ Util.pm
           |      |__ XMLRPCServer.pm
           |
           |__ tmpl/
               |__ asset-chooser.tmpl
               |__ blog_config.tmpl
               |__ datasources_table.tmpl
               |__ edit_field.tmpl
               |__ field_loop.tmpl
               |__ list_field.tmpl

Point your browser to Movable Type (mt.cgi) and you will be prompted to install CustomFields. This step will install all the tables needed by CustomFields as well as performing upgrade and maintenance tasks.
If the plugin has been correctly installed, the wizard will successfully complete and you will see the following under System Overview > Plugins

Data Storage Locations

Although the following is optional, it is recommended. By default, CustomFields stores data saved in custom fields in the general purpose mt_plugindata table. New with CustomFields 2.1, however, is the ability to store this data in custom tables of your choosing. If possible, you should instruct CustomFields to use custom tables like so:

Navigate to a blog's plugin listing screen (from the blog context, select Preferences > Plugins), click on CustomFields and click Settings. You will see the following:
Click the New Datasource link and a green bar will appear
Choose the system object type (e.g. entry, category etc.) and enter the name of the table you wish to store the data in (we recommend you choose a name that relates to the content the table will contain for example reviews or books). Note: Do not worry about creating or maintaining this table just yet!
Click Add and after a few seconds, the table will refresh.
Repeat steps 3 and 4 for all the system objects you intend to create fields for on this blog. After you have finished hit Save Changes. When the page refreshes, you will see this message at the top of the screen:
Simply click the upgrade your database link and follow the steps of the familiar wizard. This will automatically create/update your custom tables for you!

Note: Currently there is no way to migrate day from the default storage in mt_plugindata to your new custom table.

26 Comments

etherdust said:
on Aug 28, 2007 9:41 PM | Reply

Brillian idea for a plugin and will replace KeyValues quite nicely. Wish I had found this before I installed KeyValues the first time.

Sadly, I'm running into a problem. I installed CustomFields 2.1b4 per the instructions, created a new datasource, and created two fields, went through the database upgrade procedure.

When I try to use the plugin with the suggested code on the create field screen, it doesn't work. When I load the page (dynamic archives, btw), I get an error where the new code should appear:

The requested page could not be found. MTViewer::require_once(function.mtentrydatageocacheid.php) [function.MTViewer-require-once]: failed to open stream: No such file or directory

I verified that the database table and records were created that correspond to the datasource, but I don't see what the problem is.

Also of note, in my Web server's error logs, I'm seeing the following error:

[Tue Aug 28 13:27:03 2007] [error] [client 209.130.130.242] Subroutine MT::Permission::__properties redefined at /home/.ingold/etherdust/devel.etherdust.com/mt/extlib/Data/ObjectDriver/BaseObject.pm line 24., referer: http://devel.etherdust.com/mt/mt.cgi?__mode=list_field&blog_id=1

It doesn't appear when I navigate to the individual entry, but rather when I go to Preferences->CustomFields within the MT Admin UI.

Tim said:
on Aug 28, 2007 10:58 PM | Reply

I, too, am experiencing difficulties in configuring and using CustomFields 2.1b4 with MT 4.01. I was able to successfully install the plugin and add a new datasource. When I attempt to create a new field in the Entry object of type "asset", I get prompted to upgrade the database. When I do, I get the following error:

"Error during upgrade: failed to execute statement CREATE INDEX mtformsdocument ON mtforms (formsdocument): BLOB/TEXT column 'forms_document' used in key specification without a key length at lib/MT/Upgrade.pm line 1855."

So apparently there is a MySQL error.

Arvind Satyanarayan replied to etherdust's comment:
on Aug 29, 2007 5:52 AM | Reply

Hi guys,

@etherdust: The problem you're experiencing with dynamic publishing is a bug in Movable Type. I've filed a bug report and it's been fixed by Six Apart and should hopefully be in the next beta of 4.01 (or the final version). In the meanwhile, I'll email you a copy of the MTViewer.php file that fixes the problem.

The other error you are experiencing isn't really an error but a warning from Perl, so you can safely ignore it.

@Tim: Yes, that's a bug in the plugin that I thought I had fixed prior to release. You can find out how to fix it here (it's quite easy): http://plugins.movalog.com/svn/changeset/527

Lin said:
on Aug 29, 2007 12:26 PM | Reply

Hi Arvind:

Thanks for the great plugin, I have tried the v2.1b4, and found the followings:

After instaling CustomFields v2.1b4, Tag Ajax Suggestion did not working, i.e. when you create an entry, and fill out the "Tags" field, there is usually AJAX suggestion prompts the tags you entered previously, it disappeared after installing CustomFields. I tried to uninstall CustomFields (deleting the plugin folder, and restoring the database), the Tag AJAX Suggestion came back.
Will the date field be supported in the next version?
When deleting a field created by CustomField, it said the field have been deleted from the database, it was actually not, and still in the database table.
When deleting an entry, should the data entered through CustomFields also be deleted? At the moment, the entry can be deleted from the database table (mt_entry), but the data created through customfields for that entry is still in the database table.

Thanks, otherwise v2.1b4 seems working fine on my blog.

Lin

Arvind Satyanarayan replied to Lin's comment:
on Aug 29, 2007 12:34 PM | Reply

Hi Lin:

I'll have to investigate that. There shouldn't be any reason for CustomFields to prevent the tag suggestions from working
Yes date fields will be in the next beta. If you want to use them before then, check out this thread
Yes the fields won't be deleted from the database as Movable Type doesn't yet support that (nor does it really need to). The extra field in the database shouldn't result in any adverse effects, if you want to get rid of it, you can directly on the table.
Ah yes, you're quite right that if you delete a system object then it's custom data should also be deleted. That's definitely a bug!

etherdust replied to Arvind Satyanarayan's comment:
on Aug 29, 2007 2:30 PM | Reply

Arvind,

Thanks for the updated file! That helped, at least for the entries that use the custom fields.

Here's the code I have in my template:

<MTIfNonEmpty tag="EntryDataGeocacheID"> <li><img src="/images/micro/micro-geocache.png" alt="" />GeoCache: <a href="http://www.geocaching.com/seek/cache_details.aspx?wp=<MTEntryDataGeocacheID>"><MTEntryDataGeocacheID></a> <MTEntryDataGeocacheStatus></li> </MTIfNonEmpty>

For entries that use the custom fields, this works perfectly. For entries that do not use the custom fields, I receive an error:

The requested page could not be found. Invalid argument supplied for foreach()

The custom field definitions do not have them set as required, because for most entries they don't apply.

Any thoughts on that one?

Lyle said:
on Oct 1, 2007 5:51 PM | Reply

Clarification please. We're using 2.14b with MT4.0 on an Apache server with Centos 5 and MySQL.

I want to add several custom fields: "byline" and "dek" for entries; "bio" for authors. These custom fields will be used across all the blogs (25+ blogs; 20 users).

I need to create a new Datasource for each type; one new datasource for author and one new datasource for entry. I assume that all the blogs on the site will share the same new datasources. Correct?

If I have one new Datasource for a specific type, such as entry, I assume that the new Datasource holds multiple custom fields. For example, the new Datasource is "EntryAdds" and holds the custom fields: byline and dek. Correct?

Looking at the MySQL database for MT, I see that I have created a new Datasource (which is just a data table). But after upgrading, I also see a there is now a second new data table appended with the _upgrade.

Example of new tables: newDatasource and newDatasource_upgrade

What is the purpose of the second data table? And did I screw up?

Thanks for any clarification.

Lyle

Erin Riggers said:
on Oct 25, 2007 1:08 AM | Reply

I installed the plugin per directions and received confirmation that it was successful.

However, every time I try to add a field, or change the plugin configuration, I get this message:

"Your CustomFields configuration has changed. To ensure Movable Type functions properly, please upgrade your database after your configuration is complete."

I've gone through the "upgrade your database" process about five times now, and get this message each time:

"Upgrade Complete! Plugin 'CustomFields' upgraded successfully to version 2.1b4 (schema version 2.1002)."

And, the field I'm trying to add, although being told it has been saved, does not show up on my list in Preferences -> Custom Fields.

I'm running mysql 6 and MT 4.01.

What could be the issue?

Best, -e

complex said:
on Nov 20, 2007 5:30 PM | Reply

I created an object of type Entry with name "news-like_posts" for the ultimate purpose of storing a second (long) title for a post.

After saving, I was prompted to upgrade the database and got this error message: " Upgrading table for news-like_posts records...

Error during upgrade: failed to execute statement CREATE TABLE mtnews-likeposts ( news-likepostsid integer NOT NULL PRIMARY KEY ): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '-likeposts ( news-likeposts_id integer NOT NULL PRIMARY KEY )' at line 1 at lib/MT/Upgrade.pm line 1829. "

When I go to /cgi-bin/mt/mt.cgi I get prompted to update CustomFields again, and that results in this same error message.

Can you please help me get out of this?

thanks, cc

George said:
on Nov 28, 2007 6:23 AM | Reply

I ran into a little snag while upgrading. I upgraded my Movable Type to v4 and did it the "clean" way, where you re-install all the plug-ins as well. Then I installed the latest CustomFields plug-in. The fresh install of the CustomFields plug-in on the new MT did not recognize my old fields though. Perhaps I didn't read the docs all the way through.

I re-added the fields in the exact same order with the exact same parameters and still had no luck.

But, the data was still inside the mt_plugindata table. I created a new blog entry and put data in the fields that I created. Then I did an SQL dump, and looked at the binary of the data blobs to see the difference. I noticed the following:

plugindata_plugin was "CustomFields" in the new entry as opposed to "entries" in the old ones.
plugindata_data contained additional info for "customfields" in the new entry
All the field names in plugindatadata were completely lowercased with "" in the new entry instead of how it was user defined in the old entry.

Being the risk taker I am, I put together a little script that corrected the values in the old entries to the new syntax and presto change-o I have my data back.

Hope this is helpful to some folks.

Name

Email Address

URL

Comments (You may use HTML tags for style)

Please type the word "movalog" (required):

Remember personal info?

Movalog Plugins

Movable Type plugins by Arvind Satyanarayan