WordPress Rewrite Rules – The Rewrite API

WordPress Rewrite Rules – WordPress का Rewrite API, WordPress के सबसे ज्यादा Tricky Area को Represent करता है, जिसके बारे में Internet पर काफी कम जानकारी उपलब्ध है। इसलिए सबसे पहले हम इसी बात को समझने की कोशिश करते हैं कि WordPress में URLs को क्यों Rewrite किया जाता है।

Dynamic Sites में सामान्‍यत: URL के साथ Associated Query String Parameters के आधार पर Database में Stored Data द्वारा Dynamically Content Generation होता है। इन URLS को सामान्‍यत: विभिन्न प्रकार की Sub-Directories के अनुसार Static Pages के रूप में Resemble किया जाता है। ताकि ये URLs इस तरह से Recreate हो जाऐं, जैसे कि इनके द्वारा Static Directory Structure के रूप में Pages Return हो रहे हों। जबकि वास्तव में जो Page Generate हो रहे होते हैं, वे Dynamically Generate हो रहे होते हैं और Actual Web Server पर ऐसी कोई Static File या Directory Exist नहीं होती।

उदाहरण के लिए https://www.bccfalna.com/ebooks/content.html URL में Specified content ebooks नाम का कोई Folder या content.html नाम की कोई Static File Exist नहीं है। फिर भी जब URL Specify किया जाता है, जो वास्तव में जो URL, Web Server पर Submit हो रहा होता है, वह कुछ निम्नानुसार होता है:

        http://example.com/index.php?title=Rewrite_URL

जो कि WordPress System के Rewrite API द्वारा Modify करके निम्नानुसार Change कर दिया जाता है:

        http://example.com/Rewrite_URL

यानी जब Web Browser द्वारा इस URL के लिए Web Server से Request किया जाता है, तो इस URL को Web Server द्वारा Rewrite करके निम्नानुसार URL में Convert कर लिया जाता है:

        http://example.com/index.php?title=Rewrite_URL

और इसी Rewrite API के माध्‍यम से WordPress System Permalink Principle को परिभाषित कर पाता है।

Permalink Principles

Web Applications व Sites दोनों दो अलग प्रकार के Readers Read करते हैं। पहले प्रकार के Readers Human Beings होते हैं, जबकि दूसरे प्रकार के Readers को हम Search Engine Bots के रूप में Identify कर सकते हैं। इसलिए Online Resources का User व Search Engine दोनों के लिए Friendly होना जरूरी होता है।

मानलो कि हम कोई ऐसा Online Store Create करते हैं, जिसके विभिन्न Products को विभिन्न Categories में Categorize किया गया है। एक Programmer के Point of View से हर URL एक अलग Product को कुछ निम्नानुसार तरीके से Represent कर सकता है:

   http://example.com/shop.php?action=display&category=12&subcat=4

ये URL काफी आसानी से कुछ Variables Map करता है, जिनका प्रयोग करके Data को Database से Retrieve किया जा सकता है या किसी अन्‍य Action को Perform किया जा सकता है। लेकिन इस प्रकार के URL के साथ परेशानी ये है कि ये Search Engine Friendly नहीं होते और यदि Search Engine इस URL को Index करता है, तो केवल http://example.com/shop.php तक के URL को ही Index करता है, जो कि एक Single Page को Represent करता है।

जबकि वास्तव में हर Product के लिए एक अलग Web Page Generate हो सकता है, जो कि पूरी तरह से URL की ?action=display&category=12&subcat=4 Query String पर निर्भर होता है, जिसे Search Engine Index ही नहीं करते।

इसी तरह से जब हम एक Human Reader के Perspective से इस URL को देखते हैं, तब भी हालांकि एक User के रूप में इस URL को समझना काफी आसान है, लेकिन इसे याद नहीं रखा जा सकता। उदाहरण के लिए हम हमारे पिछले URL को ही देखते हैं, जिसे हम निम्नानुसार कुछ और Modify कर देते हैं:

example.com/shop.php?action=display&category=123&subcat=7&product_id=43

इस URL को हम समझ ता सकते हैं, लेकिन याद नहीं रखते। इसीलिए एक User के नजरि, से इस ULR को याद रखने की तुलना में निम्न URL को याद रखना काफी ज्यादा आसान है:

example.com/shop/programming/desktop/clanguage

इसी तरह से यदि निम्न URL को देखते हैं:

    http://example.com/index.php?year=2011 & paged=6

इस URL को याद रखने की तुलना में निम्न URL को याद रखना काफी ज्यादा सुविधाजनक हो सकता है:

    http://example.com/2011/page/6/

साथ ही जब हम Search Engine की बात करते हैं, तो Search Engines भी इस प्रकार के URL को ज्यादा महत्व देते हैं, क्योंकि इस प्रकार के URLs, Dynamically Generate होने वाले Pages को भी ठीक उसी तरह से Index करने में सक्षम होते हैं, जैसे कि ये कोई Static Page हो।

Apache mod_rewrite

Web Server Develop करने वाले Developers ने URLs को Rewrite करने के लिए कुछ तरीके Define किए हैं, जो कि Programmatically Convenient (year=2011 & paged=6) को User व Search Engine Friendly URLs (/2011/page/6/) के रूप में Convert करने हेतु उपयोगी होते हैं।

इस Section में हम जानेंगे कि Apache में URL Rewrite का काम कैसे किया जाता है, लेकिन विभिन्न प्रकार के अन्‍य Web Server Softwares जैसे कि Lighttpd, Nginx, IIS आदि में भी काफी हद तक इसी समान तरीके को Use करते हुए URL Rewriting का काम किया जाता है।

Apache में Permalinks के लिए Use होने वाला मुख्‍य Module mod_rewrite है, जो कि विभिन्न प्रकार के Rewrite Rules को .htaccess नाम की File के माध्‍यम से Define करने की सुविधा देता है। इस .htaccess File में Specify किए जाने वाले एक Classic Rewrite Rule को हम कुछ निम्नानुसार Represent कर सकते हैं।

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule [pattern] [substitution] [optional flag(s)]
</IfModule>

इस Code में Specified [pattern] व [substitution] के रूप में हम Regular Expressions को Use कर सकते हैं। जैसे:

RewriteRule /buy/([^/]+)/ /shop.php?product=$1 [L]

इस RewriteRule Statement को Specify करने के बाद User जब भी कभी Web Browser के माध्‍यम से एक ऐसे URL की Request करता है, जिसकी शुरूआत /buy/ से हो रही है व इसके बाद तब तक कोई भी Bunch of Characters हो, जबकि अन्तिम Character एक Forward Slash हो ( [^/]+ ) तो Web Server उस URL को /shop.php पर Redirect कर देता है और product Parameter को उसकी Value के साथ इस URL पर Pass कर देता है।

mod_rewrite के बारे में और ज्यादा Detail से जानने के लिए http://articles.sitepoint.com /article/guideurl-rewriting जैसे Online Resources को Use किया जा सकता है, जो कि Non-WordPress Environment में URL Rewriting के लिए सुविधा Provide करता है। लेकिन WordPress में URL Rewriting का काम कुछ अलग तरह से किया जाता है।

WordPress URL Rewriting

WordPress के /2011/03/hello-world/ जैसे किसी URL में Web Server पर कोई Physical Path नहीं होता। यानी Web Server पर “2011” नाम की Directory में “03” नाम की Directory व इस Directory में “hello-world” नाम का Folder वास्तव में Physically Exist नहीं होता।

जब WordPress को Install किया जाता है, तो WordPress अपने Root Folder में .htaccess नाम की एक File Create करता है, जिसमें निम्न Code लिखा होता है:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

इस mod_rewrite Directive में Conditional Rewrite Rules Contained होते हैं, जो Web  Server को निम्न बातें बताते हैं:

• यदि Web Browser द्वारा php के लिए Request किया गया हो, तो बिना किसी तरह का Rewrite Rule Apply किए हुए Web Server को सीधे ही index.php File पर Redirect कर दिया जाए। यहां [L] Flag का मतलब “Last” होता है।
• यदि Web Browser द्वारा Requested URL में Specified नाम की कोई Physical File Web Server पर न हो (RewriteCond %{REQUEST_FILENAME} !-f ) या
• यदि Web Browser द्वारा Requested URL में Specified नाम की कोई Physical Directory Web Server पर न हो (RewriteCond %{REQUEST_FILENAME} !-d )
• तो URL को php के लिए Rewrite किया जाए व किसी भी अन्‍य Rewrite Rule को Apply न किया जाए।

ये .htaccess Directive /2011/page/4/ Request को /index.php पर ही Redirect कर देता है। जिसका मतलब ये है कि WordPress Site के Frontend Area द्वारा Perform होने वाली हर Request Internally index.php पर ही Redirect होती है, जो WordPress के Rewrite API के माध्‍यम से इस बात को तय करता है कि Requested URL को किस प्रकार से Interpret किया जाए।