9.10. Drupal Fields API. Drupal में फील्ड्स का डेटाबेस में भंडारण।

इस लेख में हम समझेंगे कि Drupal में फील्ड्स कैसे काम करती हैं, इन्हें क्यों आवश्यकता होती है, और फील्ड्स कैसे Drupal में साइटों के त्वरित विकास में मदद करती हैं।

हम पहले ही पिछले लेखों में फील्ड्स के साथ काम कर चुके हैं:

7.5. बूटस्ट्रैप कॉलम्स के साथ सर्विसेस ब्लॉक तैयार करना

7.6. Drupal के लिए Isotope गैलरी

7.7. यूट्यूब वीडियो के साथ ब्लॉक Drupal

अब हम समझेंगे कि यह कैसे काम करता है। आइए हम आर्टिकल टाइप कंटेंट फील्ड्स को एडिट करें और एक नया Link फील्ड जोड़ें:

/admin/structure/types/manage/article/fields

जब आप नया आर्टिकल बनाएंगे, तो आपको दो इनपुट URL और टेक्स्ट लिंक मिलेंगे:

हर बार जब आप एडमिन के माध्यम से नया फील्ड बनाएंगे, तो डेटाबेस में दो टेबल्स बनाई जाएंगी:

{entity_type}___field_name}
{entity_type}_revision___field_name}

Drupal संशोधनों का समर्थन करता है, इसलिए सभी डेटा कम से कम एक बार डुप्लिकेट हो जाएगा, क्योंकि केवल संशोधन आपके आर्टिकल का वर्तमान संस्करण होता है। इस प्रकार, फील्ड्स और पूरी Drupal Fields API का उद्देश्य डेटाबेस के साथ काम को सरल बनाना है। हम बस एडमिन के माध्यम से फील्ड्स बनाते हैं, और Drupal पहले से ही डेटाबेस में टेबल्स बना देता है।

MySQL टेबल्स के नाम से यह स्पष्ट होना चाहिए कि एक ही फील्ड को एक ही प्रकार की एंटिटी के लिए इस्तेमाल किया जा सकता है। उदाहरण के लिए, हम अब Link फील्ड का उपयोग कंटेंट के Basic Page टाइप में कर सकते हैं जैसा कि पहले से मौजूद है:

/admin/structure/types/manage/page/fields/add-field

लेकिन अगर आप एक ब्लॉक में Link फील्ड बनाना चाहते हैं, तो आपको नया फील्ड बनाना होगा। आप एक अलग प्रकार की एंटिटी में एक ही फील्ड का उपयोग नहीं कर सकते। आइए हम Basic Block टाइप के लिए Link फील्ड बनाएं:

/admin/structure/block/block-content/manage/basic/fields/add-field

जैसा कि आप देख सकते हैं, जब आप फील्ड बना रहे होते हैं, तो मौजूदा फील्ड्स में से Link फील्ड का कोई चयन नहीं होता है, क्योंकि ब्लॉक और नोड अलग-अलग प्रकार की एंटिटी हैं।

और नोड्स के लिए जैसा कि हम पहले ही देख चुके हैं, ब्लॉक्स के लिए Link फील्ड डेटा को स्टोर करने के लिए दो टेबल्स होंगी:

block_content_revision__field_link और block_content__field_link.

अब हम समझते हैं कि Drupal एक ही फील्ड से विभिन्न बंडल नोड्स के लिए डेटा कैसे स्टोर करता है। हमने Article नोड प्रकार के लिए Link फील्ड बनाया था, लेकिन फिर इस फील्ड का पुनः उपयोग Basic Page नोड प्रकार में किया। सुविधा के लिए, यह सबसे अच्छा होगा कि आप साइट की कॉन्फ़िगरेशन को एक फोल्डर में अपलोड करें और फाइल्स को देखें, लेकिन आप इसे adminer या phpmyadmin के माध्यम से भी config टेबल में पा सकते हैं:

यदि आप उन सभी कॉन्फ़िगरेशन को खोजते हैं जिनमें शब्द "link" शामिल हो:

SELECT * FROM `config` WHERE CONVERT(`name` USING utf8mb4) LIKE '%link%' LIMIT 50

हम अपने field_link फील्ड के लिए निम्नलिखित कॉन्फ़िगरेशन पाएंगे:

field.field.block.block_content.basic.field_link
field.field.node.article.field_link
field.field.node.page.field_link
field.storage.block_content.field_link
field.storage.node.field_link

प्रत्येक एंटिटी प्रकार के लिए, प्रत्येक फील्ड अपनी खुद की Field Storage कॉन्फ़िगरेशन बनाता है। यह कॉन्फ़िगरेशन यह उत्तर देती है कि डेटा को {entity_type}__{field_name}, {entity_type}_revision__{field_name} टेबल्स में कैसे स्टोर किया जाएगा। हमारे मामले में, ये block_content_field_link, block_content_revision_field_link, node__field_link, node_revision__field_link टेबल्स हैं। अगला, हम देखेंगे कि Link मॉड्यूल डेटा को कैसे स्टोर करता है। आइए हम Link फील्ड के लिए Field Storage कॉन्फ़िगरेशन खोलें:

uuid: dba847ef-f4d6-4462-a2ee-f642a007fca6
langcode: en
status: true
dependencies:
  module:
    - block_content
    - link
id: block_content.field_link
field_name: field_link
entity_type: block_content
type: link
settings: {  }
module: link
locked: false
cardinality: 1
translatable: true
indexes: {  }
persist_with_no_fields: false
custom_storage: false

अब हम इन पंक्तियों को देखें ताकि यह स्पष्ट हो सके कि Field Storage कॉन्फ़िगरेशन में क्या स्टोर किया गया है।

uuid: dba847ef-f4d6-4462-a2ee-f642a007fca6

यह वह जगह है जहाँ Config ID स्टोर होती है, जो प्रत्येक Config के लिए अद्वितीय होती है। यदि आपने लोकल रूप से फील्ड बनाई है और कॉन्फ़िगरेशन अपलोड कर दी है, तो स्टेजिंग पर इसे मैन्युअल रूप से बनाने की आवश्यकता नहीं है। फील्ड स्वचालित रूप से बन जाएगी। अगर आप फील्ड को हटा देते हैं और लोकल रूप से कॉन्फ़िगरेशन हटा देते हैं, तो इसे स्टेजिंग पर इंपोर्ट करने के बाद सभी डेटा भी हट जाएंगे। इसलिए, यदि आपने स्टेजिंग पर फील्ड बनाई है, तो कॉन्फ़िगरेशन अपलोड करें और उन्हें git में जोड़ें ताकि आपके बदलाव बेकार न जाएं।

langcode: en

मल्टी-लिंग्वल साइट्स में, नोड्स के विभिन्न संस्करणों के लिए विभिन्न भाषाओं के लिए फील्ड्स की तालिका में सभी डेटा स्टोर होते हैं, जो यह दर्शाते हैं कि कौन सी भाषा विशिष्ट डेटा का उपयोग करती है:

मेरे पास वही भाषा है, इसलिए कॉन्फ़िगरेशन में डिफ़ॉल्ट भाषा वही है।

status: true

सभी कॉन्फ़िगरेशन एंटिटीज के लिए सामान्य है कि यह स्टेटस फील्ड यह दर्शाता है कि क्या यह एंटिटी सक्षम है या नहीं। Field Storage कॉन्फ़िगरेशन वह कॉन्फ़िगरेशन एंटिटी उपयोग करती है जो Drupal में बनाई जाती है, FieldStorageConfig क्लास देखें, जो ConfigEntityBase से इनहेरिटेड है:

https://api.drupal.org/api/drupal/core!modules!field!src!Entity!

dependencies:
  module:
    - block_content
    - link

एड-ऑन मॉड्यूल्स पर निर्भरता। क्योंकि हम Link फील्ड को ब्लॉक्स में उपयोग कर रहे हैं, हमारे पास Block content मॉड्यूल अनिवार्य है।

id: block_content.field_link

हमारे कॉन्फ़िगरेशन का अद्वितीय नाम।

field_name: field_link

फील्ड का मशीन नाम जो हम ने बनाया है, इसे Drupal उपयोग करता है, इसलिए इस मशीन नाम का उपयोग उदाहरण के लिए नोड ऑब्जेक्ट $node->field_link->uri तक पहुँचने के लिए किया जा सकता है। हम अगले लेखों में समझेंगे कि कैसे एंटिटी फील्ड को संदर्भित करना है।

Entity_type: block_content

हमारा Field Storage Configure किस प्रकार की एंटिटी है

type: link

Drupal फील्ड टाइप, हम अपना खुद का फील्ड टाइप बनाएंगे, अब हमें बस इतना जानना है कि यह Link प्रकार का फील्ड Link मॉड्यूल द्वारा बनाया गया है। आप क्लास देख सकते हैं:

core/modules/link/src/Plugin/Field/FieldType/LinkItem.php

जो हमारे कन्फेक्शनरी में उपयोग होती है।

settings: { }

यहाँ हम फील्ड प्रकार के लिए सेटिंग्स स्टोर करते हैं, अब ये खाली हैं, लेकिन उदाहरण के लिए, बॉडी फील्ड के लिए एक सेटिंग है कि क्या टीज़र को प्रदर्शित करना है या नहीं:

config/sync/field.field.block_content.basic.body.yml

settings:
display_summary: false

module: link

एक मॉड्यूल जो लिंक फील्ड प्रकार प्रदान करता है। अब हमारे पास मॉड्यूल का नाम और फील्ड प्रकार लिंक है, लेकिन वे अलग हो सकते हैं, उदाहरण के लिए, एक मॉड्यूल में एक से अधिक फील्ड प्रकार हो सकते हैं, जैसे कि मॉड्यूल DateTime में किया गया है:

core/modules/datetime/src/Plugin/Field/FieldType/DateTimeFieldItemList.php
core/modules/datetime/src/Plugin/Field/FieldType/DateTimeItem.php

locked: false

यह दिखाता है कि फील्ड संपादन के लिए उपलब्ध है या नहीं। इसका मतलब है फील्ड को सेटअप करना। कुछ समय पहले, उदाहरण के लिए, Commerce मॉड्यूल में बिलिंग और शिपिंग सूचना फील्ड को लॉक किया गया था क्योंकि इस फील्ड का अस्तित्व डिलीवरी और कर कैलकुलेशन के उपयोग के दौरान अनिवार्य था।

cardinality: 1

एक एंटिटी के लिए इस फील्ड के लिए दर्ज किए जा सकने वाले मानों की संख्या। हमने एक मान चुना है, लेकिन यहां और भी संख्या हो सकती है जैसे 2, 3, 5, आदि। असीमित मानों के लिए cardinality: -1 का उपयोग किया जाता है।

translatable: true

क्या यह फील्ड अन्य भाषाओं में अनुवाद योग्य है

indexes: { }

इस फील्ड में बेहतर खोज के लिए अतिरिक्त SQL इंडेक्स। आमतौर पर यह डेटाबेस क्वेरी को कॉन्फ़िगर और ऑप्टिमाइज़ करने के लिए आवश्यक होता है।

persist_with_no_fields: false

क्या सभी एंटिटी से फील्ड्स हटाए जाने पर Field Storage को हटा दिया जाए। उदाहरण के लिए, यदि हम Article और Basic Page से फील्ड को हटा देते हैं, तो Field Storage को नहीं हटाया जाएगा।

custom_storage: false

कस्टम स्टोरेज का मतलब है कि हमारे पास फील्ड डेटा स्टोर करने के लिए विशेष टेबल है, न कि {entity_type}__{field_name}। हम ऐसा कुछ नहीं उपयोग करेंगे, लेकिन कभी-कभी यह अन्य सिस्टमों के साथ एकीकरण के लिए सुविधाजनक होता है।

अब हम Link फील्ड टाइप फाइल खोलते हैं:

core/modules/link/src/Plugin/Field/FieldType/LinkItem.php

और देखते हैं कि यह फील्ड डेटाबेस में क्या डेटा स्टोर करता है। इसे propertyDefinitions() मेथड में देखा जा सकता है:

public static function propertyDefinitions(FieldStorageDefinitionInterface $field_definition) {
  $properties['uri'] = DataDefinition::create('uri')
    ->setLabel(t('URI'));
 
  $properties['title'] = DataDefinition::create('string')
    ->setLabel(t('Link text'));
 
  $properties['options'] = MapDataDefinition::create()
    ->setLabel(t('Options'));
 
  return $properties;
}

जैसा कि आप देख सकते हैं, हम URI, Title, और Options डेटा स्टोर करते हैं। यदि आप node__field_link टेबल खोलेंगे, तो आप वही फील्ड्स देखेंगे:

अब हम Drupal में Fields API पर आ गए हैं। हम एक मॉड्यूल के माध्यम से LinkItem क्लास के साथ एक फील्ड प्रकार बनाते हैं। यह हमें एंटिटी के लिए एक फील्ड बनाने की अनुमति देता है, और फिर हम इसका उपयोग डेटा दर्ज करने और इसे डेटाबेस में स्टोर करने के लिए कर सकते हैं। यह डेटा एंट्री के मामले में है। Fields API हमारे फील्ड्स के लिए डेटा एंट्री और आउटपुट के लिए फॉर्म को भी कॉन्फ़िगर करता है।

आइए हम उस समय पर वापस जाएं जब हम Article और Basic Page कंटेंट टाइप्स के लिए फील्ड्स बना रहे थे। हमारे पास Node में Field Storage के लिए एक कॉन्फ़िगरेशन फाइल है: field.storage.node.field_link.yml, लेकिन फील्ड बनाने के साथ ही, हम प्रत्येक बंडल के लिए एक और कॉन्फ़िगरेशन फाइल बनाते हैं, इसलिए उदाहरण के लिए, अब हमारे पास इस फील्ड के लिए तीन कॉन्फ़िगरेशन फाइल्स हैं:

field.field.node.article.field_link.yml
field.field.node.page.field_link.yml
field.field.block.block_content.basic.field_link.yml

इन कॉन्फ़िगरेशन्स में फील्ड सेटिंग्स फॉर्म से डेटा स्टोर होता है:

इस प्रकार हम विभिन्न बंडल्स के लिए फील्ड डेटा एंट्री के फॉर्म को विभिन्न तरीकों से कस्टमाइज़ कर सकते हैं। Drupal 8 में, Drupal 7 के विपरीत, अब फील्ड इंस्टेंस के साथ काम करने के लिए और कोई फंक्शंस नहीं हैं, और इंस्टेंस के साथ काम करने के लिए कार्यक्षमता CRUD API में माइग्रेट हो गई है:

https://www.drupal.org/node/2054619

फील्ड्स के साथ कोड के माध्यम से काम करने के उदाहरण आप आधिकारिक दस्तावेज़ में देख सकते हैं:

https://www.drupal.org/node/2012896

हमने केवल Fields API का वह हिस्सा देखा जो डेटाबेस में फील्ड डेटा के भंडारण से संबंधित है। अगले कुछ पाठों में हम देखेंगे कि Fields API डेटा एंट्री और फील्ड डेटा आउटपुट के साथ कैसे काम करता है, साथ ही हम अपना खुद का पूर्ण फील्ड प्रकार बनाएंगे।