[support] New CCK field not found in mysql

[sebastian]

Hmm, actually if I make my own radio select option, maybe that will make 
it also complex to add it to the list of available arguments in Views 
and Panels? More so than figuring our a way to access the CCK field 
directly?

My apologies if I am unaware of all the nuances involved in this 
module's development.

Thank you kindly,

Sebastian.

sebastian wrote:
> Hello again,
> 
> It's very appropriate to see this thread right now... So I've found the 
> values in the mySQL database, and they are indeed spread between:
> 
> content_node_field
> 
> and
> 
> content_field_[name_of_field]
> 
> the pairs of human readable values, and system values are also in two 
> different places, with only the machine names in the 
> content_field_[name_of_field], ug.
> 
> Since this arrangement seems to make things really convoluted, I would 
> like to ask if it would make more sense for me to create my own 
> radio/checkbox system, and to bypass the CCK system entirely?
> 
> [Especially if I want my module to function as a stand-alone for this, 
> future and possibly the Drupal community at large.]
> 
> What I am trying to accomplish is:
> 
> 1. Content Admin can select from a radiobox selection, which page they 
> want the content on
> 
> 2. Content Admin can add/remove options from the radio boxes [they only 
> see the human-readable formats], which in turn automatically 
> adds/removes pages; from their perspective the two are fundamentally the 
> same.
> 
> What goes on behind the scene:
> 
> When they add/remove options from the radio boxes, it auto generates a 
> system-readable name [removes spaces with '_' and '&' with 'and' etc.), 
> and then also adds/removes the respective menu item that matches the 
> same machine_name as the radio selection, in the format: 
> [Panel_Name]/[radio_select_option] So that the Panels page: Panel_Name 
> can be called and passed the argument: [radio_select_option].
> 
> That way, they never need to see the machine names, they never need to 
> admin two places to do one thing [adding removing menus and new options 
> appearing in the radio buttons is synonymous].
> 
> Because as it is right now, as soon as one uses Views+Panels, there is 
> no way that a non-admin can add (remove) a new menu item easily without 
> a lot of hand-holding.
> 
> I'm learning quite fast all of the system, and so I think I am going in 
> the right direction; but I am still very new to not only Drupal, but 
> also PHP/mySQL, ---
> 
> So what I am planning on doing now is bypassing CCK altogether and 
> making my own table in the DB specifically for this purpose... but 
> before I go down that road, I just wanted to check that this is indeed 
> the sane way to do it...?
> 
> BTW: I realize that doing this will mean I need to also manually add the 
> new radio box option to the $node_form too.
> 
> Thank you kindly for your time and your reply,
> 
> Sebastian.
> 
> sebastian wrote:
>> Hi William, Domenic,
>>
>> Would this also apply to reading/setting the possible values in a 
>> radio-button list of a CCK field [used by then many Nodes]? Wouldn't 
>> that just be in one single location?
>>
>> Thanks for your input!
>>
>> Kindly,
>>
>> Sebastian.
>>
>> William Smith wrote:
>>> Absolutely.  One of the things you'll find to is that where data is 
>>> stored will shift on you depending on whether the field is isolated 
>>> to one node type only or if it is shared, etc..  As Domenic said, it 
>>> really is best to use the regular node api for this sort of thing 
>>> rather than try to cram it in via direct SQL queries against the DB.
>>>
>>> On Fri, Nov 20, 2009 at 4:41 PM, Domenic Santangelo 
>>> <domenics at gmail.com <mailto:domenics at gmail.com>> wrote:
>>>
>>>     CCK is black magic... better not to try and decipher the db 
>>> structure
>>>     which at times seems kind of arbitrary to me.
>>>
>>>     The better way is to write a fn that loops thru the nodes you 
>>> want to
>>>     batch add to, do a node_load() on them, modify the desired fields,
>>>     then node_save().
>>>
>>>     HTH,
>>>     -Dom
>>>
>>>     On Nov 20, 2009, at 1:07 PM, Scott wrote:
>>>
>>>      > I found where the data went by exporting the sites database.  
>>> Rather
>>>      > than create a new table named content_field_street_name, as I 
>>> would
>>>      > have
>>>      > expected, it created content_type_[content_type_name].  This
>>>     table has
>>>      > fields: vid, nid and field_street_name_value.  I'm about out 
>>> of time
>>>      > today but I wonder what would've happened had I added two new 
>>> fields
>>>      > to
>>>      > this CCK type.
>>>      >
>>>      >
>>>      > On Fri, 2009-11-20 at 12:07 -0800, Scott wrote:
>>>      >> I've created a new field for a CCK type and it works fine in my
>>>      >> drupal
>>>      >> site.  My problem is that it does not show up in mysql 
>>> command line
>>>      >> interface or with phpmyadmin.  This is confusing to me.  I can
>>>      >> modify,
>>>      >> add and delete data using the edit node function when viewing a
>>>      >> page, so
>>>      >> I know the data is somewhere, however, I wish to do a batch 
>>> load of
>>>      >> this
>>>      >> field with mysql.
>>>      >>
>>>      >
>>>      > --
>>>      > [ Drupal support list | http://lists.drupal.org/ ]
>>>
>>>     --
>>>     [ Drupal support list | http://lists.drupal.org/ ]
>>>
>>>
>>
>