DrupalBin

Summary:

Tags:

Any tags you'd like to associate with your code, delimitered by commas (example: Views, CCK, Module, etc).

Source code: * /* * There are seven types of panels plugins at present: context, relationships, * arguments, content_types, styles, layouts, cache; Panels provides an API that * allows any module to implement these, but there's a starter set that comes * with Panels itself. They're found in the various subdirectories that live under * the Panels directory. * * All of them (but for our purposes more importantly, content types) start with * a 'plugin declaration' function like this one. ALL this function does is return * an associative array with a bunch of information for the Panels API to process. * The Panels API looks for certain keys in that array - exactly which keys depends * on the plugin type - and essentially treats the value in that key as a directive * governing how the plugin should behave. Here's what all that concretely means * for content types: * * Yes, there is some unnecessary duplication with this set of callbacks; they were * implemented in this way in order to keep from changing the Panels2 API. They will * be made consistent & elegant in Panels3. */ function panels_SAMPLE_CT_panels_content_types() { $items['SAMPLE_CT'] = array( // title (string): SETTING. The title that will be used for this pane on the 'Add Content' modal // form, and in the display content editor in general. This is a purely internal setting; // normal users will never see it. 'title' => t('Sample Content Type'), // weight (int): SETTING. Standard drupal weighting concept at work here; all it determines is the // position of this content type's icon relative to the other content type icons on the // 'Add Content' modal form. 'weight' => -10, // single (bool): SETTING. Indicates that this content type plugin provides only a single content // type. This doesn't have to be included, it's almost more of a note to humans than to // the Panels API. Check out panels_admin_content_types_block() to see how one callback // can be used to define multiple content types (technically, types AND subtypes). // Defaults to FALSE. 'single' => TRUE, // content_types (string): CALLBACK. The Panels API calls this function to get // basic information about the content types this plugin provides. See the callback // for details. 'content_types' => 'panels_admin_content_types_SAMPLE_CT', // render callback (string): CALLBACK. The Panels API calls this function when it's // trying to render the pane for viewing. See the callback for details. 'render callback' => 'panels_content_SAMPLE_CT', // add callback (string): CALLBACK. This function gets called when the user // clicks an icon to add a new pane (from the 'Add Content' modal form). // See the callback for details; note that it is often possible to use the // same, or nearly the same, callback for this as for the 'edit callback.' 'add callback' => 'panels_admin_add_SAMPLE_CT', // edit callback (string): CALLBACK. This function gets called when the user // clicks the 'Configure' button; it partially governs what appears on the // configuration modal form that pops up. 'edit callback' => 'panels_admin_edit_SAMPLE_CT', // (add|edit) validate callback (string): CALLBACK. Defines a callback to be // used as a FAPI validator, but only for the $form_values set by form items // defined in the 'add/edit callback'. 'add validate callback' => 'panels_admin_add_validate_SAMPLE_CT', 'edit validate callback' => 'panels_admin_edit_validate_SAMPLE_CT', // (add|edit) submit callback (string): CALLBACK. Defines a callback to be // used as a FAPI submit handler, but only for the $form_values set by form // items defined in the 'add/edit callback'. 'add submit callback' => 'panels_admin_add_submit_SAMPLE_CT', 'edit submit callback' => 'panels_admin_edit_submit_SAMPLE_CT', // title callback (string): CALLBACK. This function determines the title that // the pane will use, both in the admin interface and for general viewing. Note // that this can almost always be overridden 'title callback' => 'panels_admin_title_SAMPLE_CT', // visibility control (string): CALLBACK. This function gets called at the same // time as the add/edit callbacks. Use it to create a form widget that allowing the // user to select values that will make sense when passed to your 'visibility check' // callback. 'visibility control' => 'panels_admin_visibility_control_SAMPLE_CT', // visibility submit (string): CALLBACK. The custom submit handler you define // for your content type's visibility settings. This function is passed // whatever selection the user makes on the form widget defined by the // 'visibility control' callback. Implement this if you need to wrangle that // data before the Panels API's data storage routines kick in, or if the API's // built-in routines are inadequate and you need to build a custom storage // mechanism. See panels_content_config_form() and panels_content_config_form_submit() // to grok the logic behind if/when/how this callback is triggered. 'visibility submit' => 'panels_admin_visibility_submit_SAMPLE_CT', // visibility check (string): CALLBACK. The Panels API calls this function during // the pane accessibility checking routine - that's done in panels_pane_access(). // Define the logic governing your content type's visibility here. 'visibility check' => 'panels_content_visibility_SAMPLE_CT', // visibility serialize (bool): SETTING. Set this to 'true' if the contents of // $pane->visibility need to be serialized before being written to the database. // Set this to TRUE if, for example, your visibility form widget uses checkboxes // (and therefore generates an array), as opposed to if your widget uses radios // (and therefore generates an integer that can be stored directly). See // panels_content_config_form_submit() and panels_save_display() to better // understand how this works. // Defaults to FALSE. 'visibility serialize' => TRUE, // role-based access (bool): SETTING. Boolean setting to indicate whether you // want the your content type to utilize the Panels API's built-in access // system, which is based on drupal user roles. Set this to FALSE to disable // role-based access. Note that this will automatically be set to FALSE if // a 'visibility control' callback is defined. // Defaults to TRUE. 'role-based access' => FALSE, // roles and visibility (bool): SETTING. If you want your content type to use // both your custom visibility logic and Panels' built-in roles-based access // system, then set this to TRUE. Setting 'role-based access' to TRUE is not // sufficient; see panels_ajax_ct_preconfigure() to understand how this works. // If you use both systems, panels_pane_access() will AND the results together // when determining pane visibility. 'roles and visibility' => TRUE, // form control (string): CALLBACK. If the other callbacks governing the add/edit // form ('add/edit callback', 'visibility control') aren't enough for your needs, // then implement this callback. The callback will be passed a fully-built $form object // by reference, and you can alter it as you see fit. Use with caution. 'form control' => 'panels_admin_form_control_node_content', ); return $items; }

Syntax highlighting mode: ActionScriptColdFusionDiffDrupalDrupal 5Drupal 6HTMLJavascriptMySQLPHPPythonrobots.txtSQLText

Select the syntax highlighting mode to use.