Note that there are some explanatory texts on larger screens.

plurals
  1. POHow do you add fields to com_content in Joomla! with a plugin and store the data in its own table?
    primarykey
    data
    text
    <p>I'm running Joomla 1.7 and I know that it has the ability to add custom form fields to components with a plugin.</p> <p>There is a sample plugin located at: /plugins/user/profile</p> <p>This plugin allows you to put custom form fields on the user profile front end and back end and these fields are stored in a custom table.</p> <p>I created a similar plugin for user profiles and it worked perfectly.</p> <p>However, when I go to create a plugin like this for com_content, I am met with a problem.</p> <p>this is what my XML file looks like:</p> <pre><code>&lt;?xml version="1.0" encoding="utf-8"?&gt; &lt;form&gt; &lt;fields name="additionalinfo"&gt; &lt;fieldset name="additionalinfo_fieldset" label="PLG_CONTENT_ADDITIONALINFO_FIELDSET_LABEL"&gt; &lt;field name="tagline" type="text" size="50" default="" label="PLG_CONTENT_ADDITIONALINFO_TAGLINE_LABEL" description="PLG_CONTENT_ADDITIONALINFO_TAGLINE_DESC" /&gt; &lt;field name="pseudocategory" type="category" extension="com_content" label="PLG_CONTENT_ADDITIONALINFO_PSEUDOCATEGORY_FIELD_LABEL" description="PLG_CONTENT_ADDITIONALINFO_PSEUDOCATEGORY_FIELD_DESC" /&gt; &lt;/fieldset&gt; &lt;/fields&gt; &lt;/form&gt; </code></pre> <p>This however does not work, whenever I do something like above, the form fields never show up on the admin form (even though I have it set correctly, and the only thing that changed between the user plugin and the content plugin is the name of the form i'd like the form to appear on</p> <p>When I change my XML to this:</p> <pre><code>&lt;?xml version="1.0" encoding="utf-8"?&gt; &lt;form&gt; &lt;fields name="attribs"&gt; &lt;fieldset name="additionalinfo_fieldset" label="PLG_CONTENT_ADDITIONALINFO_FIELDSET_LABEL"&gt; &lt;field name="tagline" type="text" size="50" default="" label="PLG_CONTENT_ADDITIONALINFO_TAGLINE_LABEL" description="PLG_CONTENT_ADDITIONALINFO_TAGLINE_DESC" /&gt; &lt;field name="pseudocategory" type="category" extension="com_content" label="PLG_CONTENT_ADDITIONALINFO_PSEUDOCATEGORY_FIELD_LABEL" description="PLG_CONTENT_ADDITIONALINFO_PSEUDOCATEGORY_FIELD_DESC" /&gt; &lt;/fieldset&gt; &lt;/fields&gt; &lt;/form&gt; </code></pre> <p>When I make this simple change, the form fields show up! BUT, the data isn't stored or retrieved from the custom table, it just goes into the 'attribs' column on the _content table. This stores the content in JSON, which is alright, but we'd like to be able to index the content by the custom fields (and not have to loop through each record in the database to find what we're looking for).</p> <p>Any ideas on how to fix this?</p> <p>thanks!</p> <p>david barratt</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. COJust curious, is there a reason you are not using a CCK for this? This is pretty much exactly the point of a CCK.
      singulars
    2. CO@BrentFriar Most of the CCK's for Joomla! that i've seen are terrible. For instance, Zoo stores all of the data in XML in a single database field. This is terrible for indexing. Also, the CCKs are usually poorly integrated with the rest of Joomla! so the search does not respond accordingly. Also, existing modules designed for com_content will not pull in contentment from CCK's so any modules that could have been used no longer can be. However, I do agree that Joomla! needs an integrated CCK of some sort. However, storing fields in separate tables is somewhat close.
      singulars
    3. COI am afraid that putting extra fields in a single database field is the way you will find it in most instances. It's not really a problem for indexing or search at least for the large CCKs because there are plugins that handle those tasks, as it should be. You will also find that most of the big developers also support some of the various CCKs. If you have a module that does not, it is trivial to change the SQL statements to work with a CCK. All of this is well worth not having to write a rather complex work around. you should seriously try some CCKs before committing to writing your own.
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload