| PELICAN(1) | PELICAN | PELICAN(1) |
نام (NAME)
pelican - مستندات ابزار pelican
ابزار Pelican یک سازنده وبسایت ایستا است که با زبان Python https://www.python.org نوشته شده است. نکات برجسته آن عبارتند از:
- محتوای خود را مستقیماً با ویرایشگر دلخواه خود در قالبهای reStructuredText http://docutils.sourceforge.net/rst.html یا Markdown https://daringfireball.net/projects/markdown بنویسید
- شامل یک ابزار خط فرمانی ساده برای تولید (یا تولید مجدد) وبسایت شما
- تعامل و اتصال آسان با سامانههای توزیعشده کنترل نسخه و وبهوکها
- خروجی کاملاً ایستا که میزبانی آن را در هر مکانی آسان میسازد
آماده شروع هستید؟ راهنمای شروع سریع (Quickstart) <> را بررسی کنید.
ویژگیها (FEATURES)
ویژگیهای برجسته Pelican عبارتند از:
- مقالهها (مانند پستهای وبلاگ) و صفحهها (مانند "درباره ما"، "پروژهها"، "تماس با ما")
- یکپارچهسازی با سرویسهای خارجی
- پوستههای سایت (ساختهشده با استفاده از قالبهای Jinja2 https://palletsprojects.com/p/jinja)
- انتشار مقالهها به چند زبان
- تولید فیدهای Atom و RSS
- برجستهسازی نحوی کدها (Syntax Highlighting)
- درونریزی محتوای موجود از WordPress، Dotclear یا فیدهای RSS
- سرعت بالا در بازتولید به لطف حافظه پنهان محتوا و نوشتن گزینشی خروجی
- توسعهپذیر از طریق زیستبوم غنی افزونهها: Pelican Plugins https://github.com/pelican-plugins
چرا نام «PELICAN»؟ (WHY THE NAME "PELICAN"?)
واژه "Pelican" یک واروواژه (آناگرام) از کلمه فرانسوی calepin است که به معنای "دفترچه یادداشت" میباشد. ;)
کد منبع (SOURCE CODE)
میتوانید به کد منبع در این آدرس دسترسی داشته باشید: https://github.com/getpelican/pelican
راهنمایی، مشارکت یا ارسال بازخورد (HOW TO GET HELP, CONTRIBUTE, OR PROVIDE FEEDBACK)
دستورالعملهای ارسال بازخورد و مشارکت ما را بررسی کنید <>.
مستندات (DOCUMENTATION)
شروع سریع (Quickstart)
خواندن تمامی مستندات اکیداً توصیه میشود، اما برای کسانی که شکیبایی کمتری دارند، در ادامه مراحلی سریع برای شروع آورده شده است.
نصب (Installation)
ابزار Pelican (و اختیاری Markdown در صورت تمایل به استفاده) را روی Python >=3.9 با اجرای دستور زیر در ترمینال دلخواه خود نصب کنید؛ در صورت نیاز به مجوزهای مدیریتی، دستور را با sudo آغاز کنید:
python -m pip install "pelican[markdown]"
ایجاد یک پروژه (Create a project)
نخست، نامی برای پروژه خود انتخاب کنید، دایرکتوری مناسبی برای سایت خود بسازید و وارد آن شوید:
mkdir -p ~/projects/yoursite cd ~/projects/yoursite
یک پروژه اولیه و خام را از طریق دستور pelican-quickstart بسازید؛ این دستور با پرسیدن چند پرسش پیرامون وبسایت شما آغاز میشود:
pelican-quickstart
برای پرسشهایی که مقادیر پیشفرض آنها داخل قلاب نشان داده شده است، میتوانید با فشردن کلید Return آن مقادیر پیشفرض را بپذیرید [1]. هنگامی که از شما پیشوند نشانی وب (URL prefix) خواسته شد، نام دامنه خود را مطابق راهنما (برای نمونه، https://example.com) وارد نمایید..SS ایجاد یک مقاله
تا زمانی که محتوایی ایجاد نکرده باشید، نمیتوانید Pelican را اجرا کنید. با استفاده از ویرایشگر متنی مورد علاقه خود، نخستین مقاله را با محتوای زیر بسازید:
Title: My First Review Date: 2010-12-03 10:20 Category: Review Following is a review of my favorite mechanical keyboard.
با توجه به اینکه این مقاله نمونه در قالب Markdown است، آن را با عنوان ~/projects/yoursite/content/keyboard-review.md ذخیره کنید.
تولید وبسایت
از دایرکتوری ریشه پروژه خود، دستور pelican را برای تولید وبسایت اجرا کنید:
pelican content
اکنون وبسایت شما درون دایرکتوری output/ تولید شده است. (ممکن است هشداری در رابطه با خوراکها مشاهده کنید، اما این مورد هنگام توسعه محلی طبیعی است و فعلاً میتوان آن را نادیده گرفت.)
پیشنمایش وبسایت
یک نشست ترمینال جدید باز کنید، به دایرکتوری ریشه پروژه بروید، و دستور زیر را برای راهاندازی سرور وب Pelican اجرا کنید:
pelican --listen
با رفتن به http://localhost:8000 در مرورگر خود، پیشنمایش وبسایت را مشاهده کنید.
برای جزئیات بیشتر به خواندن سایر بخشهای مستندات ادامه دهید، و صفحه راهنماهای ویکی Pelican https://github.com/getpelican/pelican/wiki/Tutorials را برای پیوندهای مربوط به آموزشهای ارائهشده توسط جامعه کاربری بررسی کنید.
پاورقیها
- [1]
- میتوانید با نصب ماژول اختیاری tzlocal https://pypi.org/project/tzlocal به بومیسازی فیلدهای پیشفرض کمک کنید.
نصب Pelican
در حال حاضر Pelican روی >=3.9 به بهترین شکل اجرا میشود؛ نسخههای قدیمیتر Python پشتیبانی نمیشوند.
میتوانید Pelican را با چندین روش مختلف نصب کنید. سادهترین روش از طریق Pip https://pip.pypa.io است:
python -m pip install pelican
یا، اگر قصد استفاده از Markdown را دارید:
python -m pip install "pelican[markdown]"
(به یاد داشته باشید که در برخی سیستمعاملها برای نصب Pelican به صورت سراسری در سیستم، لازم است در ابتدای دستور بالا sudo اضافه کنید.)
اگرچه روش بالا سادهترین شیوه است، اما روش توصیهشده ساخت یک محیط مجازی برای Pelican از طریق virtualenv https://virtualenv.pypa.io/en/latest پیش از نصب Pelican است. با فرض اینکه virtualenv https://virtualenv.pypa.io/en/latest را نصب کردهاید، میتوانید یک نشست ترمینال جدید باز کرده و یک محیط مجازی جدید برای Pelican ایجاد کنید:
virtualenv ~/virtualenvs/pelican cd ~/virtualenvs/pelican source bin/activate
پس از ایجاد و فعالسازی محیط مجازی، Pelican میتواند همانطور که در بالا اشاره شد از طریق python -m pip install pelican نصب شود. همچنین، اگر کد منبع پروژه را در اختیار دارید، میتوانید Pelican را با استفاده از روش distutils نصب کنید:
cd path-to-Pelican-source python setup.py install
اگر Git نصب دارید و ترجیح میدهید آخرین نسخه لبه توسعه (bleeding-edge) Pelican را به جای یک انتشار پایدار نصب کنید، از دستور زیر استفاده کنید:
python -m pip install -e "git+https://github.com/getpelican/pelican.git#egg=pelican"
پس از نصب Pelican، میتوانید برای دیدن گزینههای پایهای کاربرد، pelican --help را اجرا کنید. برای جزئیات بیشتر، به بخش Publish <> مراجعه کنید..SS بستههای اختیاری
اگر قصد دارید از Markdown https://pypi.org/project/Markdown به عنوان یک قالب نشانهگذاری استفاده کنید، میتوانید Pelican را با پشتیبانی از Markdown نصب کنید:
python -m pip install "pelican[markdown]"
بهبودهای تایپوگرافی را میتوان در فایل تنظیمات فعال کرد، اما ابتدا باید کتابخانهٔ الزامی Typogrify https://pypi.org/project/typogrify نصب شود:
python -m pip install typogrify
وابستگیها
هنگام نصب Pelican، بستههای پایتونی وابستهٔ زیر باید به طور خودکار و بدون نیاز به هیچ اقدامی از سوی شما نصب شوند:
- feedgenerator https://pypi.org/project/feedgenerator، برای تولید فیدهای Atom
- jinja2 https://pypi.org/project/Jinja2، برای پشتیبانی از قالبها
- pygments https://pypi.org/project/Pygments، برای برجستهسازی نحو
- docutils https://pypi.org/project/docutils، برای پشتیبانی از reStructuredText به عنوان یک قالب ورودی
- blinker https://pypi.org/project/blinker، یک سامانهٔ سیگنالدهی شیءبهشیء و پخشی (broadcast)
- unidecode https://pypi.org/project/Unidecode، برای نویسهگردانی متنهای یونیکد به ASCII
- MarkupSafe https://pypi.org/project/MarkupSafe، برای پیادهسازی رشتههای ایمن در برابر نشانهگذاری
- python-dateutil https://pypi.org/project/python-dateutil، برای خواندن فرادادههای تاریخ
ارتقا
اگر نسخهٔ پایدار Pelican را از طریق Pip https://pip.pypa.io نصب کردهاید و مایلید آن را به آخرین نسخهٔ پایدار ارتقا دهید، میتوانید این کار را با افزودن --upgrade انجام دهید:
python -m pip install --upgrade pelican
اگر Pelican را از طریق distutils یا روش توسعهٔ پیشرو (bleeding-edge) نصب کردهاید، کافی است همان مرحله را برای نصب جدیدترین نسخه تکرار کنید.
راهاندازی سریع وبگاه
پس از نصب Pelican، میتوانید با استفاده از دستور pelican-quickstart که کار خود را با پرسیدن چند پرسش دربارهٔ وبگاه شما آغاز میکند، ساختار اولیهٔ یک پروژه را ایجاد کنید:
pelican-quickstart
اگر در یک محیط مجازی فعال اجرا شود، pelican-quickstart به دنبال مسیر پروژهٔ مرتبط درون $VIRTUAL_ENV/.project خواهد گشت. اگر آن فایل وجود داشته باشد و حاوی مسیر دایرکتوری معتبری باشد، پروژهٔ جدید Pelican در آن مکان ذخیره خواهد شد. در غیر این صورت، پیشفرض دایرکتوری کاری جاری است. برای تنظیم مسیر پروژهٔ جدید در فراخوانی اولیه، از این دستور استفاده کنید: pelican-quickstart --path /your/desired/directory
پس از پایان پاسخگویی به تمام پرسشها، پروژهٔ شما شامل ساختار سلسلهمراتبی زیر خواهد بود (به جز pages — که در زیر درون پرانتز نشان داده شده است — و در صورتی که قصد ایجاد محتوای غیرگاهشمارانه دارید میتوانید خودتان به صورت اختیاری آن را اضافه کنید):
yourproject/ ├── content │ └── (pages) ├── output ├── tasks.py ├── Makefile ├── pelicanconf.py # Main settings file └── publishconf.py # Settings to use when ready to publish
گام بعدی، شروع افزودن محتوا به پوشهٔ content است که برای شما ایجاد شده است.
نوشتن محتوا
مقالهها و صفحهها
Pelican موارد گاهشمارانه مانند پستهای وبلاگ را "articles" (مقالهها) در نظر میگیرد و از این رو آنها را به یک تاریخ مرتبط میسازد.
ایدهٔ نهفته در "pages" (صفحهها) این است که معمولاً ماهیت زمانی ندارند و برای محتوایی استفاده میشوند که چندان تغییر نمیکند (برای نمونه، صفحههای "About" یا "Contact").
میتوانید محتوای نمونه را در مخزن در مسیر samples/content/ پیدا کنید..SS "فراداده فایل (File metadata)"
Pelican تلاش میکند به اندازه کافی هوشمند باشد تا اطلاعات مورد نیاز خود را از سامانه فایل دریافت کند (برای مثال، درباره دستهبندی مقالههای شما)، اما برخی از اطلاعات را باید در قالب فراداده درون فایلهای خود ارائه دهید.
اگر محتوای خود را در قالب reStructuredText مینویسید، میتوانید این فراداده را در فایلهای متنی از طریق نحو زیر ارائه دهید (پسوند .rst را به فایل خود بدهید):
My super title ############## :date: 2010-10-03 10:20 :modified: 2010-10-04 18:40 :tags: thats, awesome :category: yeah :slug: my-super-post :authors: Alexis Metaireau, Conan Doyle :summary: Short version for index and feeds
فهرستهای نویسندگان و برچسبها میتوانند در عوض با نقطه-ویرگول از هم جدا شوند، که به شما امکان میدهد نویسندگان و برچسبهای حاوی کاما بنویسید:
:tags: pelican, publishing tool; pelican, bird :authors: Metaireau, Alexis; Doyle, Conan
Pelican افزونهای را برای reStructuredText پیادهسازی میکند تا پشتیبانی از برچسب HTML به نام abbr فعال شود. برای استفاده از آن، چیزی شبیه به این در پست خود بنویسید:
This will be turned into :abbr:`HTML (HyperText Markup Language)`.
همچنین میتوانید از نحو Markdown استفاده کنید (با فایلی با پسوند .md، .markdown، .mkd، یا .mdown). تولید Markdown نیازمند این است که ابتدا بسته Python-Markdown https://github.com/Python-Markdown/markdown را به صورت صریح نصب کنید، که میتواند از طریق pip install Markdown انجام شود.
همچنین Pelican از Markdown Extensions https://python-markdown.github.io/extensions پشتیبانی میکند، که در صورت عدم وجود در بسته پیشفرض Markdown ممکن است نیاز باشد جداگانه نصب شوند و میتوان آنها را از طریق تنظیمات MARKDOWN پیکربندی و بارگذاری کرد.
نحو فراداده برای پستهای Markdown باید از این الگو پیروی کند:
Title: My super title Date: 2010-12-03 10:20 Modified: 2010-12-05 19:30 Category: Python Tags: pelican, publishing Slug: my-super-post Authors: Alexis Metaireau, Conan Doyle Summary: Short version for index and feeds This is the content of my super blog post.
همچنین میتوانید کلیدهای فراداده اختصاصی خود را داشته باشید (تا زمانی که با کلمات کلیدی رزرو شده فراداده تداخل نداشته باشند) تا در قالبهای خود استفاده کنید. جدول زیر حاوی فهرستی از کلمات کلیدی رزرو شده فراداده است:
| فراداده | توضیحات |
| title | عنوان مقاله یا صفحه |
| date | تاریخ انتشار (برای مثال، YYYY-MM-DD HH:SS) |
| modified | تاریخ ویرایش (برای مثال، YYYY-MM-DD HH:SS) |
| tags | برچسبهای محتوا، جدا شده با کاما |
| keywords | کلمات کلیدی محتوا، جدا شده با کاما (فقط محتوای HTML) |
| category | دستهبندی محتوا (فقط یکی — نه چندگانه) |
| slug | شناسه مورد استفاده در URLها و ترجمهها |
| author | نویسنده محتوا، زمانی که فقط یکی باشد |
| authors | نویسندگان محتوا، زمانی که چندگانه باشند |
| summary | توضیح کوتاه محتوا برای صفحات نمایه |
| lang | شناسه زبان محتوا (en، fr و غیره) |
| translation | آیا محتوا ترجمهای از محتوای دیگر است (true یا false) |
| status | وضعیت محتوا: draft، hidden، skip، یا published |
| template | نام قالب مورد استفاده برای تولید محتوا (بدون پسوند) |
| save_as | ذخیره محتوا در این مسیر نسبی فایل |
| url | آدرس URL برای استفاده در این مقاله/صفحه |
خوانندهها (Readers) برای قالبهای بیشتر (مانند AsciiDoc https://asciidoc.org) از طریق افزونهها در دسترس هستند، که میتوانید آنها را از طریق مجموعه Pelican Plugins https://github.com/pelican-plugins و همچنین مخزن قدیمی pelican-plugins https://github.com/getpelican/pelican-plugins بیابید.
همچنین Pelican میتواند فایلهای HTML منتهی به .html و .htm را پردازش کند. Pelican سند HTML را به روشی بسیار ساده تفسیر میکند، به این صورت که فراداده را از برچسبهای meta، عنوان را از برچسب title، و بدنه را از برچسب body میخواند:
<html>
<head>
<title>My super title</title>
<meta name="tags" content="thats, awesome" />
<meta name="date" content="2012-07-09 22:28" />
<meta name="modified" content="2012-07-10 20:14" />
<meta name="category" content="yeah" />
<meta name="authors" content="Alexis Métaireau, Conan Doyle" />
<meta name="summary" content="Short version for index and feeds" />
</head>
<body>
This is the content of my super blog post.
</body>
</html>
در مورد HTML، یک استثنای ساده برای فراداده استاندارد وجود دارد: برچسبها را میتوان هم از طریق فراداده tags (همانطور که در Pelican استاندارد است) و هم از طریق فراداده keywords (همانطور که در HTML استاندارد است) مشخص کرد. این دو را میتوان به جای یکدیگر استفاده کرد.
توجه داشته باشید که به جز عنوان، هیچیک از این فرادادههای محتوا اجباری نیستند: اگر تاریخ مشخص نشده باشد و DEFAULT_DATE روی 'fs' تنظیم شده باشد، Pelican به برچسب زمانی "mtime" فایل تکیه خواهد کرد، و دستهبندی میتواند از روی دایرکتوریای که فایل در آن قرار دارد تعیین شود. برای مثال، فایلی که در python/foobar/myfoobar.rst قرار دارد، دستهبندی foobar را خواهد داشت. اگر میخواهید فایلهای خود را به روشهای دیگری سازماندهی کنید که در آن نام زیرپوشه نام مناسبی برای دستهبندی نیست، میتوانید مقدار USE_FOLDER_AS_CATEGORY را روی False قرار دهید. هنگام تجزیه تاریخهای ارائهشده در فراداده صفحه، Pelican از زیرمجموعه پیشنهادی W3C برای ISO 8601 https://www.w3.org/TR/NOTE-datetime پشتیبانی میکند.
بنابراین عنوان تنها فراداده الزامی است. اگر این موضوع شما را نگران میکند، نگران نباشید. به جای مشخص کردن دستی عنوان در فراداده در هر بار، میتوانید از نام فایل منبع محتوا به عنوان عنوان استفاده کنید. برای مثال، به یک فایل منبع Markdown با نام Publishing via Pelican.md به طور خودکار عنوان Publishing via Pelican اختصاص داده میشود. اگر این رفتار را ترجیح میدهید، خط زیر را به فایل تنظیمات خود اضافه کنید:
FILENAME_METADATA = '(?P<title>.*)'
نکته:
مقدار modified باید آخرین زمانی باشد که مقاله را بهروزرسانی کردهاید، و اگر مشخص نشود پیشفرض آن date خواهد بود. علاوه بر اینکه میتوانید modified را در قالبها نمایش دهید، ورودیهای فید در فیدخوانها زمانی که پس از ویرایش مقاله، modified را به تاریخ فعلی تنظیم کنید، به طور خودکار بهروزرسانی خواهند شد.
مقدار authors فهرستی از نویسندگان مقاله است که با کاما از هم جدا شدهاند. اگر تنها یک نویسنده وجود دارد میتوانید از فیلد author استفاده کنید.
اگر فراداده summary را برای یک پست خاص به طور صریح مشخص نکنید، میتوان از تنظیم SUMMARY_MAX_LENGTH برای تعیین تعداد کلماتی از ابتدای مقاله که به عنوان خلاصه استفاده میشوند، استفاده کرد. همچنین میتوانید با استفاده از تنظیم SUMMARY_MAX_PARAGRAPHS از N پاراگراف اول مقاله به عنوان خلاصه آن استفاده کنید. اگر از هر دو تنظیم استفاده شود، تعداد پاراگرافهای مشخصشده استفاده خواهد شد اما ممکن است برای رعایت حداکثر طول مشخصشده کوتاه شوند.
همچنین میتوانید از طریق یک عبارت باقاعده که در تنظیم FILENAME_METADATA تعیین میشود، هر فرادادهای را از نام فایل استخراج کنید. همه گروههای نامگذاریشدهای که تطبیق داده شوند در شیء فراداده قرار خواهند گرفت. مقدار پیشفرض برای تنظیم FILENAME_METADATA تنها تاریخ را از نام فایل استخراج میکند. برای مثال، اگر میخواهید هم تاریخ و هم slug را استخراج کنید، میتوانید مقداری شبیه به این تنظیم کنید: '(?P<date>\d{4}-\d{2}-\d{2})_(?P<slug>.*)'
لطفاً توجه داشته باشید که فراداده موجود درون فایلهای شما بر فراداده استخراجشده از نام فایل اولویت دارد..SS برگهها (Pages)
اگر پوشهای به نام pages در پوشهٔ content ایجاد کنید، تمام فایلهای درون آن برای تولید برگههای ایستا، مانند برگههای About یا Contact استفاده خواهند شد. (نمونه ساختار سیستمفایل را در زیر ببینید.)
میتوانید از تنظیم DISPLAY_PAGES_ON_MENU برای کنترل اینکه آیا همهٔ این برگهها در منوی ناوبری اصلی نمایش داده شوند یا خیر استفاده کنید. (پیشفرض True است.)
اگر میخواهید برگهای را از پیوند داده شدن یا فهرست شدن در منو مستثنی کنید، ویژگی status: hidden را به فرادادههای (metadata) آن بیفزایید. این ویژگی برای مواردی مانند ساخت برگههای خطا که با پوستهٔ تولیدشدهٔ وبگاه شما همخوانی دارند، مفید است.
محتوای ایستا (Static content)
فایلهای ایستا، فایلهایی غیر از مقالهها و برگهها هستند که بدون پردازش و به همان شکل بهصورت مستقیم در پوشهٔ خروجی کپی میشوند. میتوانید فایلهای ایستای کپیشده را با تنظیم STATIC_PATHS در فایل pelicanconf.py پروژه کنترل کنید. پیکربندی پیشفرض Pelican شامل دایرکتوری images برای این منظور است، اما سایر موارد باید بهصورت دستی افزوده شوند. علاوه بر این، فایلهای ایستایی که صراحتاً پیوند داده شدهاند نیز گنجانده میشوند (زیر را ببینید).
نکته:
محتوای مختلط در یک دایرکتوری (Mixed content in the same directory)
از نسخهٔ Pelican 3.5 به بعد، فایلهای ایستا میتوانند بدون افشای سورس برگهها در وبگاه تولیدشده، با فایلهای سورس برگهها در یک دایرکتوری مبدأ به اشتراک گذاشته شوند. هر دایرکتوری از این دست باید به هر دوی STATIC_PATHS و PAGE_PATHS (یا STATIC_PATHS و ARTICLE_PATHS) افزوده شود. Pelican فایلهای سورس برگه را بهطور عادی شناسایی و پردازش میکند و باقی فایلها را بهگونهای کپی میکند که گویی در دایرکتوری مجزایی مخصوص فایلهای ایستا قرار دارند.
نکته: قرار دادن فایلهای ایستا و فایلهای سورس محتوا در کنار هم در یک دایرکتوری مبدأ، تضمین نمیکند که آنها در وبگاه تولیدشده نیز در همان مکان قرار گیرند. سادهترین راه برای انجام این کار، استفاده از ساختار پیوند {attach} است (در زیر توضیح داده شده است). همچنین، میتوان تنظیمات STATIC_SAVE_AS، PAGE_SAVE_AS و ARTICLE_SAVE_AS (و تنظیمات متناظر *_URL) را برای قرار دادن فایلهایی از انواع مختلف در کنار هم پیکربندی کرد، درست همانند نسخههای پیشین Pelican.
پیوند به محتوای داخلی (Linking to internal content)
از نسخهٔ Pelican 3.1 به بعد، اکنون امکان تعیین پیوندهای درونوبگاهی به فایلها در سلسلهمراتب محتوای مبدأ بهجای فایلها در سلسلهمراتب تولیدشده وجود دارد. این کار پیوند دادن از پست فعلی به محتواهای دیگری را که ممکن است در کنار آن پست قرار داشته باشند آسانتر میکند (بهجای اینکه نیاز باشد مکان قرارگیری محتوای دیگر پس از تولید وبگاه مشخص شود).
برای پیوند به محتوای داخلی (فایلهای موجود در دایرکتوری content)، از ساختار زیر برای مقصد پیوند استفاده کنید: {filename}path/to/file. نکته: اسلش رو به جلو، /، در دستورالعمل {filename} در تمام سیستمعاملها، از جمله Windows، جداکنندهٔ مسیر اجباری است.
برای نمونه، یک پروژهٔ Pelican ممکن است ساختاری شبیه به این داشته باشد:
website/ ├── content │ ├── category/ │ │ └── article1.rst │ ├── article2.md │ └── pages │ └── about.md └── pelican.conf.py
در این مثال، article1.rst میتواند به این شکل باشد:
The first article
#################
:date: 2012-12-01 10:02
See below intra-site link examples in reStructuredText format.
`a link relative to the current file <{filename}../article2.md>`_
`a link relative to the content root <{filename}/article2.md>`_
و article2.md:
Title: The second article
Date: 2012-12-01 10:02
See below intra-site link examples in Markdown format.
[a link relative to the current file]({filename}category/article1.rst)
[a link relative to the content root]({filename}/category/article1.rst)
پیوند به فایلهای ایستا (Linking to static files)
میتوانید با استفاده از {static}path/to/file به محتوای ایستا پیوند دهید. فایلهایی که با این ساختار پیوند داده میشوند، بهطور خودکار در دایرکتوری خروجی کپی خواهند شد، حتی اگر دایرکتوریهای مبدأ حاوی آنها در تنظیم STATIC_PATHS فایل pelicanconf.py پروژه گنجانده نشده باشند.
برای نمونه، دایرکتوری محتوای یک پروژه ممکن است چنین ساختاری داشته باشد:
content ├── images │ └── han.jpg ├── pdfs │ └── menu.pdf └── pages └── test.md
فایل test.md شامل این موارد خواهد بود:

[Our Menu]({static}/pdfs/menu.pdf)
سپس فرایند تولید وبگاه، فایل han.jpg را در output/images/han.jpg و فایل menu.pdf را در output/pdfs/menu.pdf کپی کرده و پیوندهای مناسب را در test.md درج میکند.
اگر از {static} برای پیوند به یک مقاله یا برگه استفاده کنید، این پیوند به پیوندی به کد سورس آن تبدیل خواهد شد..SS پیوست کردن فایلهای ایستا
از Pelican 3.5 به بعد، فایلهای ایستا را میتوان با استفاده از این نحو برای مقصد پیوند به یک صفحه یا مقاله "پیوست" کرد: {attach}path/to/file. این نحو مانند نحو {static} عمل میکند، اما علاوه بر آن، فایل ایستا را به دایرکتوری خروجیِ سند پیونددهنده نیز منتقل میکند. اگر فایل ایستا در یک زیردایرکتوری زیر منبع سند پیونددهنده قرار داشته باشد، آن رابطه در خروجی حفظ خواهد شد. در غیر این صورت، در کنار سند پیونددهنده (در همان سطح) قرار خواهد گرفت.
این قابلیت تنها برای پیوند دادن به فایلهای ایستا کار میکند.
برای نمونه، دایرکتوری محتوای (content) یک پروژه ممکن است چنین ساختاری داشته باشد:
content
├── blog
│ ├── icons
│ │ └── icon.png
│ ├── photo.jpg
│ └── testpost.md
└── downloads
└── archive.zip
فایل pelicanconf.py شامل این موارد خواهد بود:
PATH = 'content'
ARTICLE_PATHS = ['blog']
ARTICLE_SAVE_AS = '{date:%Y}/{slug}.html'
ARTICLE_URL = '{date:%Y}/{slug}.html'
فایل testpost.md شامل این موارد خواهد بود:
Title: Test Post
Category: test
Date: 2014-10-31


[Downloadable File]({attach}/downloads/archive.zip)
تولید سایت در این حالت دایرکتوری خروجیای با ساختار زیر ایجاد خواهد کرد:
output
└── 2014
├── archive.zip
├── icons
│ └── icon.png
├── photo.jpg
└── test-post.html
توجه کنید که تمام فایلهای پیوند داده شده با استفاده از {attach} در دایرکتوری خروجی مقاله یا زیردایرکتوریهای آن قرار گرفتهاند.
اگر به یک فایل ایستا چندین بار پیوند داده شود، ویژگی جابهجاییِ {attach} تنها برای اولین پیوندی که پردازش میشود عمل خواهد کرد. پس از اولین پیوند، Pelican با {attach} همانند {static} رفتار خواهد کرد. این کار از شکسته شدن پیوندهایی که قبلاً پردازش شدهاند جلوگیری میکند.
هنگام پیوند دادن به یک فایل از چندین سند، احتیاط کنید: از آنجا که نخستین پیوند به یک فایل مکان آن را نهایی میکند و Pelican ترتیبی برای پردازش اسناد مشخص نمیکند، استفاده از {attach} برای فایلی که در چندین سند پیوند داده شده است میتواند موجب تغییر مکان آن از یک ساخت سایت به ساخت بعدی شود. (اینکه آیا این اتفاق در عمل رخ میدهد یا خیر، به سیستمعامل، سیستم فایل، نسخه Pelican و اسنادی که به پروژه اضافه، ویرایش یا حذف میشوند بستگی دارد.) در نتیجه، ممکن است پیوندهای هر سایت بیرونی که به مکان پیشین فایل پیوند دارد شکسته شود. بنابراین توصیه میشود تنها در صورتی از {attach} استفاده کنید که آن را در تمامی پیوندها به آن فایل به کار ببرید، و تنها در صورتی که اسناد پیونددهنده در یک دایرکتوری مشترک قرار داشته باشند. تحت این شرایط، مکان خروجی فایل در ساختهای بعدی تغییر نخواهد کرد. در مواردی که رعایت این احتیاطها ممکن نیست، استفاده از پیوندهای {static} را به جای {attach} مد نظر قرار دهید و اجازه دهید مکان فایل بر اساس تنظیمات STATIC_SAVE_AS و STATIC_URL پروژه تعیین شود. (بازنویسیهای جداگانه برای هر فایل با save_as و url را همچنان میتوان در EXTRA_PATH_METADATA تعیین کرد.)
نکته:
پیوند دادن به نویسندگان، دستهها، نمایه و برچسبها
میتوانید با استفاده از نحو {author}name، {category}foobar، {index} و {tag}tagname به نویسندگان، دستهها، نمایه و برچسبها پیوند دهید.
نحو منسوخ پیوند درونی
جهت حفظ سازگاری با نسخههای پیشین، Pelican همچنان علاوه بر آکولاد ({}) از خطوط عمودی (||) برای پیوندهای درونی پشتیبانی میکند. برای نمونه: |filename|an_article.rst، |tag|tagname، |category|foobar. این نحو از || به {} تغییر یافت تا از تداخل با افزونههای Markdown یا رهنمودهای reST جلوگیری شود. به طور مشابه، Pelican هنوز هم از پیوند دادن به محتوای ایستا با {filename} پشتیبانی میکند. این نحو به {static} تغییر پیدا کرد تا پیوند دادن هم به مقالهها و صفحههای تولیدشده و هم به منابع ایستای آنها امکانپذیر باشد.
پشتیبانی از نحو قدیمی ممکن است در آینده برداشته شود..SS گنجاندن فایلهای دیگر
هر دو نحو Markdown و reStructuredText سازوکارهایی را برای این کار ارائه میدهند.
در ادامه چند مثال برای reStructuredText با استفاده از راهنمای include http://docutils.sourceforge.net/docs/ref/rst/directives.html#include آمده است:
.. include:: file.rst
گنجاندن بخشی از یک فایل که با دو شناسه مشخص شده است، به همراه رنگآمیزی نحو برای C++ (برش زدن بر اساس شماره خطوط نیز ممکن است):
.. include:: main.cpp
:code: c++
:start-after: // begin
:end-before: // end
گنجاندن یک فایل خام HTML (یا یک SVG درونخطی) و قرار دادن مستقیم آن در خروجی بدون هیچگونه پردازشی:
.. raw:: html
:file: table.html
برای Markdown باید به یک افزونه متکی بود. برای مثال با استفاده از پلاگین mdx_include https://github.com/neurobin/mdx_include:
```html
{! template.html !}
```
وارد کردن یک سایت موجود
امکان وارد کردن سایت شما از چندین سرویس وبلاگنویسی دیگر (مانند WordPress، Tumblr و...) با استفاده از یک اسکریپت ساده وجود دارد. بخش وارد کردن یک سایت موجود را ببینید <#import>.
ترجمهها
ترجمه مقالهها امکانپذیر است. برای این کار باید مشخصه فراداده lang را به مقالهها/صفحات خود اضافه کرده و تنظیم DEFAULT_LANG (که بهطور پیشفرض انگلیسی [en] است) را مشخص کنید. با اعمال این تنظیمات، تنها مقالههای دارای زبان پیشفرض فهرست خواهند شد و هر مقاله با فهرستی از ترجمههای دردسترس برای آن مقاله همراه خواهد بود.
نکته:
بهطور پیشفرض، Pelican از "slug" در نشانی مقاله استفاده میکند تا تشخیص دهد آیا دو یا چند مقاله ترجمه یکدیگر هستند یا خیر. (این رفتار با تنظیم ARTICLE_TRANSLATION_ID قابل تغییر است.) مقدار slug میتواند بهصورت دستی در فراداده فایل تنظیم شود؛ در صورتی که بهطور صریح تنظیم نشود، Pelican بهطور خودکار slug را از عنوان مقاله تولید خواهد کرد.
در اینجا مثالی از دو مقاله آورده شده است، یکی به زبان انگلیسی و دیگری به فرانسوی.
مقاله انگلیسی:
Foobar is not dead ################## :slug: foobar-is-not-dead :lang: en That's true, foobar is still alive!
و نسخه فرانسوی:
Foobar n'est pas mort ! ####################### :slug: foobar-is-not-dead :lang: fr Oui oui, foobar est toujours vivant !
صرفنظر از کیفیت محتوای پست، مشاهده میکنید که تنها مورد مشترک بین دو مقاله، slug است که در اینجا به عنوان یک شناسه عمل میکند. اگر ترجیح میدهید slug را به این شیوه بهطور صریح تعریف نکنید، باید در عوض مطمئن شوید که عناوین مقالههای ترجمهشده یکسان باشند، چرا که slug بهطور خودکار از عنوان مقاله تولید خواهد شد.
اگر نمیخواهید نسخه اصلی یک مقاله خاص با تنظیم DEFAULT_LANG شناسایی شود، از فراداده translation برای مشخص کردن اینکه کدام پستها ترجمه هستند استفاده کنید:
Foobar is not dead ################## :slug: foobar-is-not-dead :lang: en :translation: true That's true, foobar is still alive!
Pelican میتواند برجستهسازی رنگی نحو را برای بلوکهای کد شما ارائه دهد. برای انجام این کار، باید از قراردادهای زیر در فایلهای محتوای خود استفاده کنید.
برای reStructuredText، از دستورالعمل code-block برای مشخص کردن نوع کدی که باید برجسته شود استفاده کنید (در این مثالها، از python استفاده میکنیم):
.. code-block:: python
print("Pelican is a static site generator.")
برای Markdown، که از افزونه CodeHilite https://python-markdown.github.io/extensions/code_hilite/#syntax برای ارائه برجستهسازی نحو بهره میبرد، شناسه زبان را دقیقاً بالای بلوک کد قرار دهید و هم شناسه و هم کد را دندانهگذاری کنید:
There are two ways to specify the identifier:
:::python
print("The triple-colon syntax will *not* show line numbers.")
To display line numbers, use a path-less shebang instead of colons:
#!python
print("The path-less shebang syntax *will* show line numbers.")
شناسه مشخصشده (مانند python، ruby) باید شناسهای باشد که در فهرست تحلیلگران لغوی (lexers) موجود https://pygments.org/docs/lexers آمده است.
هنگام استفاده از reStructuredText، گزینههای زیر در دستورالعمل code-block در دسترس هستند:
| گزینه | مقادیر معتبر | توضیحات |
| anchorlinenos | N/A | در صورت وجود، شماره خطوط را در برچسبهای <a> قرار میدهد. |
| classprefix | string | رشتهای که به ابتدای نام کلاسهای توکن افزوده میشود |
| hl_lines | numbers | فهرست خطوطی که باید برجسته شوند؛ شماره خطوط برای برجستهسازی با یک فاصله از هم جدا میشوند. این گزینه مشابه emphasize-lines در Sphinx است، اما از بازهای از شماره خطوط که با خط تیره یا کاما جدا شده باشند، پشتیبانی نمیکند. |
| lineanchors | string | هر خط را با استفاده از این رشته و -linenumber در یک لنگر (anchor) قرار میدهد. |
| linenos | string | در صورت وجود یا تنظیم روی "table"، شماره خطوط را در یک جدول خروجی میدهد؛ اگر روی "inline" تنظیم شود، آنها را بهصورت درونخطی خروجی میدهد. مقدار "none" یعنی شماره خطوط برای این جدول خروجی داده نشود. |
| linenospecial | number | در صورت تنظیم، به هر nامین خط، کلاس CSS با نام 'special' اختصاص مییابد. |
| linenostart | number | شماره خط برای خط نخست. |
| linenostep | number | چاپ شماره خط برای هر nامین خط. |
| lineseparator | string | رشتهای که بین خطوط کد چاپ میشود؛ بهطور پیشفرض 'n'. |
| linespans | string | هر خط را با استفاده از این و -linenumber در یک span قرار میدهد. |
| nobackground | N/A | در صورت تنظیم، رنگ پسزمینه برای عنصر دربرگیرنده خروجی داده نمیشود. |
| nowrap | N/A | در صورت تنظیم، توکنها بههیچوجه دربرگرفته (wrap) نمیشوند. |
| tagsfile | string | فایل ctags مورد استفاده برای تعاریف نامها. |
| tagurlformat | string | قالب برای پیوندهای ctag. |
توجه داشته باشید که بسته به نسخه، ممکن است ماژول Pygments شما همه این گزینهها را در دسترس نداشته باشد. برای جزئیات بیشتر درباره هر یک از گزینهها به بخش HtmlFormatter در مستندات Pygments https://pygments.org/docs/formatters مراجعه کنید.
برای مثال، بلوک کد زیر شماره خطوط را با شروع از 153 فعال میکند و پیشوند کلاسهای CSS مربوط به Pygments را برابر با pgcss قرار میدهد تا نامها یکتاتر شده و از تداخلهای احتمالی CSS جلوگیری شود:
.. code-block:: identifier
:classprefix: pgcss
:linenos: table
:linenostart: 153
<indented code block goes here>
همچنین میتوان متغیر PYGMENTS_RST_OPTIONS را در فایل تنظیمات Pelican مشخص کرد تا شامل گزینههایی باشد که بهطور خودکار روی هر بلوک کد اعمال شوند.
برای مثال، اگر میخواهید شماره خطوط و یک پیشوند CSS برای هر بلوک کد نمایش داده شود، این متغیر را بدینصورت تنظیم میکنید:
PYGMENTS_RST_OPTIONS = {'classprefix': 'pgcss', 'linenos': 'table'}
در صورت تعیین، تنظیمات مربوط به هر بلوک کد مجزا، مقادیر پیشفرض موجود در فایل تنظیمات شما را بازنویسی خواهند کرد..SS "انتشار پیشنویسها (Publishing drafts)"
اگر میخواهید یک مقاله یا برگه را به عنوان پیشنویس منتشر کنید (برای مثال، جهت بازبینی توسط دوستان پیش از انتشار نهایی)، میتوانید ویژگی Status: draft را به فرادادههای (metadata) آن اضافه کنید. آن مقاله سپس در پوشهٔ drafts خروجی داده خواهد شد و نه در صفحهٔ اصلی (index) و نه در هیچیک از صفحات دستهبندی یا برچسب فهرست نخواهد شد.
اگر مایلید مقالات شما به طور خودکار به عنوان پیشنویس منتشر شوند (تا از انتشار تصادفی مقاله قبل از پایان نگارش آن جلوگیری شود)، وضعیت را در DEFAULT_METADATA قرار دهید:
DEFAULT_METADATA = {
'status': 'draft',
}
برای انتشار پستی که وضعیت پیشفرض آن draft است، فرادادهٔ پست را بهروزرسانی کرده و مقدار Status: published را در آن قرار دهید.
پستهای پنهان (Hidden Posts)
همانند برگهها، پستها را نیز میتوان با مشخصهٔ Status: hidden به صورت hidden نشانهگذاری کرد. پستهای پنهان طبق انتظار در مسیر ARTICLE_SAVE_AS خروجی داده میشوند، اما به صورت پیشفرض در فهرستهای برچسب، دستهبندی و نویسنده، و همچنین در فید اصلی مقالات قرار نخواهند گرفت. این عمل اثری معادل ایجاد یک پست «فهرستنشده» ("unlisted") دارد.
صرفنظر از پستها (Skip Posts)
پستهایی که با وضعیت skip نشانهگذاری شده باشند کاملاً نادیده گرفته میشوند. آنها نه پردازش میشوند و نه در مسیر ARTICLE_SAVE_AS ذخیره میگردند. این دسته از پستها نیز در فهرستها یا فیدها گنجانده نخواهند شد.
انتشار سایت (Publish your site)
تولید سایت (Site generation)
پس از نصب Pelican و در دست داشتن محتوا (مثلاً در قالب Markdown یا reST)، میتوانید با استفاده از دستور pelican و مشخص کردن مسیر محتوا و (به طور اختیاری) مسیر فایل تنظیمات <>، محتوای خود را به HTML تبدیل کنید:
pelican /path/to/your/content/ [-s path/to/your/settings.py]
دستور فوق سایت شما را تولید کرده و آن را در پوشهٔ output/ ذخیره میکند و با استفاده از پوستهٔ پیشفرض، سایتی ساده میسازد. پوستهٔ پیشفرض شامل HTML بسیار ساده و فاقد استایل ظاهری است تا افراد بتوانند از آن به عنوان پایهای برای ساخت پوستههای اختصاصی خود استفاده کنند.
شما همچنین میتوانید به Pelican دستور دهید تا تغییرات فایلها را پایش کند، به جای اینکه هر بار برای مشاهدهٔ تغییرات دستور را دستی اجرا کنید. برای فعالسازی این مورد، دستور pelican را با گزینهٔ -r یا --autoreload اجرا کنید. در محیطهای غیر از ویندوز، این گزینه را میتوان با گزینهٔ -l یا --listen ترکیب کرد تا همزمان خروجی به صورت خودکار بازتولید شده و در آدرس http://localhost:8000 ارائه شود:
pelican --autoreload --listen
گزینههای خط فرمان دیگری نیز برای Pelican موجود است. برای مشاهدهٔ تمام گزینههای قابل استفاده، راهنما را بررسی کنید:
pelican --help
مشاهده فایلهای تولیدشده (Viewing the generated files)
فایلهای تولیدشده توسط Pelican از نوع ایستا (static) هستند، بنابراین برای مشاهدهٔ آنها نیاز به ابزار خاصی ندارید. میتوانید از مرورگر خود برای باز کردن مستقیم فایلهای HTML تولیدشده استفاده کنید:
firefox output/index.html
از آنجا که روش فوق ممکن است در یافتن مسیر فایلهای CSS و سایر داراییهای پیوندیافته با مشکل مواجه شود، اجرای وبسرور داخلی سادهٔ Pelican معمولاً تجربهٔ پیشنمایش مطمئنتری ارائه میدهد:
pelican --listen
پس از راهاندازی وبسرور، میتوانید سایت خود را در نشانی زیر پیشنمایش کنید: http://localhost:8000
استقرار (Deployment)
پس از تولید سایت، پیشنمایش آن در محیط توسعهٔ محلی و آماده شدن برای استقرار در محیط عملیاتی (production)، ممکن است ابتدا بخواهید سایت خود را با تنظیمات خاص محیط عملیاتی (مانند سرویسهای تحلیل آماری، فیدها و غیره) که تعریف کردهاید، مجدداً بازتولید کنید:
pelican content -s publishconf.py
برای پایهگذاری پیکربندی انتشار خود بر روی pelicanconf.py، میتوانید تنظیمات pelicanconf را با افزودن خط زیر به فایل publishconf.py وارد (import) کنید:
from pelicanconf import *
اگر فایل publishconf.py را با استفاده از دستور pelican-quickstart ایجاد کرده باشید، این خط به صورت پیشفرض در آن گنجانده شده است.
مراحل استقرار سایت شما به بستر میزبانی آن بستگی دارد. اگر دسترسی SSH به سروری دارید که Nginx یا Apache را اجرا میکند، میتوانید از ابزار rsync برای انتقال فایلهای سایت خود استفاده نمایید:
rsync -avc --delete output/ host.example.com:/var/www/your-site/
گزینههای استقرار متعدد دیگری نیز در دسترس هستند که برخی از آنها را میتوان هنگام راهاندازی اولیهٔ سایت از طریق دستور pelican-quickstart پیکربندی کرد. برای جزئیات مربوط به انتشار از طریق GitHub Pages، صفحهٔ Tips <> را ببینید..SS "خودکارسازی (Automation)"
در حالی که دستور pelican روش استاندارد و مرجع برای تولید وبسایت شما است، ابزارهای خودکارسازی میتوانند برای سادهسازی و بهبود فرآیند تولید و انتشار به کار روند. یکی از پرسشهایی که در طول فرآیند pelican-quickstart پرسیده میشود، مربوط به این است که آیا مایلید تولید و انتشار وبسایت را خودکارسازی کنید یا خیر. اگر به آن پرسش پاسخ "yes" داده باشید، یک فایل tasks.py و یک Makefile در ریشهٔ پروژهٔ شما تولید خواهد شد. این فایلها که با اطلاعات مشخصی برگرفته از سایر پاسخهای ارائه شده در طول فرآیند pelican-quickstart از پیش پر شدهاند، به عنوان یک نقطهٔ شروع در نظر گرفته شدهاند و باید متناسب با نیازها و الگوهای مصرف خاص شما سفارشیسازی شوند. اگر احساس میکنید یک یا هر دوی این ابزارهای خودکارسازی کاربرد محدودی برای شما دارند، این فایلها در هر زمان قابل حذف هستند و تأثیری بر استفاده از دستور اصلی و استاندارد pelican نخواهند گذاشت.
در ادامه ابزارهای خودکارسازی آورده شدهاند که دستور pelican را پوشش میدهند ("wrap" میکنند) و میتوانند فرآیند تولید، پیشنمایش، و بارگذاری سایت شما را سادهتر نمایند.
Invoke
مزیت Invoke https://www.pyinvoke.org این است که به زبان Python نوشته شده و بنابراین میتواند در طیف گستردهای از محیطها استفاده شود. نکتهٔ منفی آن این است که باید به صورت جداگانه نصب شود. برای نصب Invoke از دستور زیر استفاده کنید؛ در صورتی که محیط شما نیاز دارد، sudo را به ابتدای آن بیفزایید:
python -m pip install invoke
کمی وقت بگذارید تا فایل tasks.py را که در ریشهٔ پروژهٔ شما ایجاد شده است باز کنید. تعدادی دستور مشاهده خواهید کرد که هر یک از آنها را میتوان به دلخواه تغییر نام داد، حذف کرد و/یا سفارشیسازی نمود. با استفاده از پیکربندی پیشفرض، میتوانید وبسایت خود را از طریق دستور زیر تولید کنید:
invoke build
اگر ترجیح میدهید Pelican هر بار با تشخیص یک تغییر، سایت شما را بهطور خودکار بازتولید کند (که هنگام آزمایش و بررسی محلی بسیار سودمند است)، در عوض از دستور زیر استفاده کنید:
invoke regenerate
برای ارائهٔ (serve) سایت تولیدشده به طوری که بتوان آن را در مرورگر در نشانی http://localhost:8000 پیشنمایش کرد:
invoke serve
برای ارائهٔ سایت تولیدشده به همراه بارگذاری مجدد خودکار در مرورگر با هر بار تشخیص تغییر، ابتدا دستور python -m pip install livereload را اجرا کرده، سپس دستور زیر را به کار ببرید:
invoke livereload
اگر در حین فرآیند pelican-quickstart هنگام پرسش دربارهٔ تمایل به بارگذاری سایت از طریق SSH پاسخ "yes" دادهاید، میتوانید از دستور زیر برای انتشار سایت خود از طریق rsync بر بستر SSH استفاده نمایید:
invoke publish
اینها تنها چند مورد از دستورهای موجود به طور پیشفرض هستند؛ بنابراین در بررسی tasks.py و مشاهدهٔ سایر دستورهای موجود تردید نکنید. مهمتر از آن، بدون درنگ tasks.py را بر اساس نیازها و ترجیحات خاص خود سفارشیسازی کنید.
Make
یک Makefile نیز زمانی که در حین فرآیند pelican-quickstart به پرسش مربوطه پاسخ "yes" بدهید، به طور خودکار برای شما ایجاد میشود. مزیت این روش در این است که دستور make به طور توکار در اغلب سیستمهای POSIX وجود دارد و از این رو برای استفاده از آن نیازی به نصب مورد دیگری نیست. نکتهٔ منفی این است که سیستمهای غیر POSIX (مانند Windows) شامل make نیستند، و نصب آن بر روی این سیستمها میتواند کار دشوار و غیربدیهی باشد.
اگر میخواهید از make برای تولید سایت با استفاده از تنظیمات موجود در pelicanconf.py استفاده کنید، دستور زیر را اجرا کنید:
make html
جهت تولید سایت برای محیط عملیاتی (production)، با بهرهگیری از تنظیمات publishconf.py، دستور زیر را اجرا کنید:
make publish
اگر ترجیح میدهید Pelican با هر بار شناسایی تغییرات سایت شما را بهطور خودکار مجدداً تولید کند (که هنگام آزمایش محلی بسیار مفید است)، به جای آن از دستور زیر استفاده کنید:
make regenerate
برای ارائهٔ سایت تولیدشده به گونهای که بتوان آن را در مرورگر در آدرس http://localhost:8000 پیشنمایش کرد:
make serve
در حالت عادی لازم است دستورهای make regenerate و make serve را در دو نشست پایانهٔ جداگانه اجرا کنید، اما میتوانید هر دو را به صورت همزمان با دستور زیر اجرا نمایید:
make devserver
دستور فوق بهطور همزمان Pelican را در حالت بازتولید اجرا کرده و خروجی را نیز در نشانی http://localhost:8000 ارائه میدهد.
هنگامی که آمادهٔ انتشار سایت خود شدید، میتوانید آن را از طریق روش(هایی) که در طول پرسشنامهٔ pelican-quickstart برگزیدهاید بارگذاری نمایید. برای این مثال، از rsync بر بستر ssh استفاده میکنیم:
make rsync_upload
کار تمام است! اکنون وبسایت شما باید زنده و برخط باشد.
(اسکریپتهای پیشفرض Makefile و devserver.sh از فایلهای اجرایی python و pelican برای انجام وظایف خود استفاده میکنند. در صورت تمایل به استفاده از فایلهای اجرایی دیگر، مانند python3، میتوانید به ترتیب متغیرهای محیطی PY و PELICAN را تنظیم کنید تا نام فایلهای اجرایی پیشفرض را بازنویسی کنند.).SS تنظیمات (Settings)
Pelican به لطف یک فایل تنظیمات که میتوانید به خط فرمان بدهید، قابل پیکربندی است:
pelican content -s path/to/your/pelicanconf.py
اگر از دستور pelican-quickstart استفاده کرده باشید، فایل تنظیمات اصلی شما بهطور پیشفرض pelicanconf.py نام خواهد داشت.
همچنین میتوانید تنظیمات را از طریق پرچمهای گزینهٔ -e / --extra-settings مشخص کنید. این گزینه هم تنظیمات پیشفرض و هم هر تنظیم تعریفشده درون فایل تنظیمات را بازنویسی خواهد کرد. توجه داشته باشید که مقادیر باید از نشانهگذاری JSON پیروی کنند:
pelican content -e SITENAME='"A site"' READERS='{"html": null}' CACHE_CONTENT=true
متغیرهای محیطی نیز میتوانند در اینجا استفاده شوند، اما باید بهدرستی گریزدهی (escape) شوند:
pelican content -e API_KEY=''\"$API_KEY\"''
نکته:
تنظیمات در قالب یک ماژول پایتون (یک فایل) پیکربندی میشوند. یک فایل تنظیمات نمونه در https://raw.githubusercontent.com/getpelican/pelican/main/samples/pelican.conf.py برای ارجاع در دسترس است.
برای مشاهدهٔ فهرستی از تنظیمات فعلی در محیط خود، شامل مقادیر پیشفرض و هر مقدار سفارشیشده، دستور زیر را اجرا کنید (برای دیدن مقادیر فقط مربوط به تنظیماتی خاص، یک یا چند نام تنظیم را به عنوان آرگومان اضافه کنید):
pelican --print-settings
تمام شناسههای تنظیمات باید با حروف بزرگ نوشته شوند، در غیر این صورت پردازش نخواهند شد. مقادیر تنظیمی که عدد (5، 20 و غیره)، مقادیر بولی (True، False، None و غیره)، دیکشنری یا تاپل هستند نباید در علامت نقلقول قرار گیرند. تمام مقادیر دیگر (یعنی رشتهها) باید درون علامت نقلقول قرار داده شوند.
مگر در مواردی که صراحتاً خلاف آن قید شده باشد، تنظیماتی که به مسیرها ارجاع میدهند میتوانند مطلق یا نسبی نسبت به فایل پیکربندی باشند. تنظیماتی که در فایل پیکربندی تعریف میکنید به قالبها ارسال خواهند شد، که به شما امکان میدهد از تنظیمات خود برای افزودن محتوا در سراسر وبگاه استفاده کنید.
در ادامه فهرستی از تنظیمات Pelican آمده است:
تنظیمات پایه (Basic settings)
- USE_FOLDER_AS_CATEGORY = True
- هنگامی که دستهای را در فرادادهٔ پست خود مشخص نکنید، در صورت تنظیم این گزینه روی True و سازماندهی مقالهها در زیرپوشهها، نام زیرپوشه به دستهٔ پست شما تبدیل خواهد شد. اگر روی False تنظیم شود، DEFAULT_CATEGORY به عنوان جایگزین استفاده خواهد شد.
- DEFAULT_CATEGORY = 'misc'
- دستهٔ پیشفرض برای استفاده در صورت مشخص نشدن دسته.
- DISPLAY_PAGES_ON_MENU = True
- اینکه آیا برگهها در منوی قالب نمایش داده شوند یا خیر. قالبها ممکن است این تنظیم را رعایت کنند یا نکنند.
- DISPLAY_CATEGORIES_ON_MENU = True
- اینکه آیا دستهها در منوی قالب نمایش داده شوند یا خیر. قالبها ممکن است این تنظیم را رعایت کنند یا نکنند.
- DOCUTILS_SETTINGS = {}
- تنظیمات پیکربندی اضافی برای ناشر docutils (تنها برای reStructuredText قابل اعمال است). برای جزئیات بیشتر به تنظیمات پیکربندی Docutils در http://docutils.sourceforge.net/docs/user/config.html مراجعه کنید.
- DELETE_OUTPUT_DIRECTORY = False
- حذف دایرکتوری خروجی و تمام محتویات آن، پیش از تولید فایلهای جدید. این تنظیم میتواند در جلوگیری از باقی ماندن فایلهای قدیمی و غیرضروری در خروجی مفید باشد. با این حال، این یک تنظیم مخرب است و باید با احتیاط بسیار زیاد به کار رود.
- OUTPUT_RETENTION = []
- فهرستی از
نام
فایلها که
باید در
دایرکتوری
خروجی حفظ
شوند و حذف
نشوند. یکی
از موارد
استفاده
میتواند
حفظ
دادههای
سیستم
کنترل نسخه
باشد.
مثال:
OUTPUT_RETENTION = [".hg", ".git", ".bzr"]
- JINJA_ENVIRONMENT = {'trim_blocks': True, 'lstrip_blocks': True}
- یک دیکشنری از متغیرهای محیطی سفارشی Jinja2 که میخواهید استفاده کنید. این همچنین شامل فهرستی از افزونههایی است که ممکن است بخواهید اضافه کنید. مستندات Jinja Environment در https://jinja.palletsprojects.com/en/latest/api/#jinja2.Environment را ببینید.
- JINJA_FILTERS = {}
- یک دیکشنری
از
فیلترهای
سفارشی Jinja2 که
میخواهید
استفاده
کنید. این
دیکشنری
باید نام
فیلتر را به
تابع فیلتر
نگاشت کند.
مثال:
import sys
sys.path.append('to/your/path')
from custom_filter import urlencode_filter
JINJA_FILTERS = {'urlencode': urlencode_filter}
ببینید: مستندات فیلترهای سفارشی Jinja در https://jinja.palletsprojects.com/en/latest/api/#custom-filters.
- JINJA_GLOBALS = {}
- یک دیکشنری از اشیاء سفارشی برای نگاشت در فضای نام محیط سراسری Jinja2. این دیکشنری باید نام سراسری را به متغیر/تابع سراسری نگاشت کند. ببینید: مستندات فضای نام سراسری Jinja در https://jinja.palletsprojects.com/en/latest/api/#the-global-namespace.
- JINJA_TESTS = {}
- یک دیکشنری از تستهای سفارشی Jinja2 که میخواهید استفاده کنید. این دیکشنری باید نامهای تست را به توابع تست نگاشت کند. ببینید: مستندات تستهای سفارشی Jinja در https://jinja.palletsprojects.com/en/latest/api/#custom-tests.
- LOG_FILTER = []
- فهرستی از
تاپلهای
حاوی سطح
لاگ (تا warning) و
پیامی که
باید
نادیده
گرفته شود.
مثال:
LOG_FILTER = [(logging.WARN, 'TAG_SAVE_AS is set to False')]
- READERS = {}
- یک دیکشنری
از
پسوندهای
فایل /
کلاسهای Reader
تا Pelican آنها
را پردازش
کند یا
نادیده
بگیرد.
برای نمونه، جهت جلوگیری از پردازش فایلهای .html، قرار دهید:
READERS = {'html': None}
برای افزودن یک خواننده (reader) سفارشی برای پسوند foo، قرار دهید:
READERS = {'foo': FooReader}
برای دیدن فهرست کاملی از فایلهای معمولاً پنهان تنظیمشده توسط watchfiles.DefaultFilter، لطفاً به مستندات watchfiles به نشانی https://watchfiles.helpmanual.io/api/filters/#watchfiles.DefaultFilter.ignore_dirs مراجعه کنید.
- MARKDOWN = {...}
- تنظیمات
پیکربندی
اضافی برای
پردازشگر Markdown.
برای
مشاهدهٔ
فهرست
کاملی از
گزینههای
پشتیبانیشده،
به بخش Options در
مستندات Python Markdown
به نشانی
https://python-markdown.github.io/reference/#markdown
مراجعه
کنید.
گزینهٔ extensions
بهطور
خودکار بر
اساس
گزینهٔ extension_configs
محاسبه
خواهد شد.
مقدار پیشفرض:
MARKDOWN = {
'extension_configs': {
'markdown.extensions.codehilite': {'css_class': 'highlight'},
'markdown.extensions.extra': {},
'markdown.extensions.meta': {},
},
'output_format': 'html5',
}
نکته:
- OUTPUT_PATH = 'output/'
- محل ذخیرهٔ فایلهای تولیدشده. این مسیر باید با دایرکتوری ریشهٔ میزبان مجازی (virtual host) وبسرور شما مطابقت داشته باشد.
- PATH
- مسیر دایرکتوری محتوا برای پردازش توسط Pelican. اگر تعریف نشده باشد، و مسیر محتوا نیز از طریق آرگومانی به دستور pelican مشخص نشده باشد، Pelican از دایرکتوری کاری فعلی استفاده خواهد کرد.
- PAGE_PATHS = ['pages']
- فهرستی از دایرکتوریها و فایلها برای جستجوی برگهها، بهصورت نسبی نسبت به PATH.
- PAGE_EXCLUDES = []
- فهرستی از دایرکتوریها برای مستثنی کردن هنگام جستجوی برگهها، علاوه بر ARTICLE_PATHS.
- ARTICLE_PATHS = ['']
- فهرستی از دایرکتوریها و فایلها برای جستجوی مقالهها، بهصورت نسبی نسبت به PATH.
- ARTICLE_EXCLUDES = []
- فهرستی از دایرکتوریها برای مستثنی کردن هنگام جستجوی مقالهها، علاوه بر PAGE_PATHS.
- OUTPUT_SOURCES = False
- اگر میخواهید مقالهها و برگهها با قالب اصلی خود (مانند Markdown یا reStructuredText) در OUTPUT_PATH مشخصشده کپی شوند، این گزینه را روی True تنظیم کنید.
- OUTPUT_SOURCES_EXTENSION = '.text'
- پسوندی را که توسط SourcesGenerator استفاده میشود کنترل میکند. پیشفرض .text است. اگر یک رشتهٔ معتبر نباشد، از مقدار پیشفرض استفاده خواهد شد.
- PLUGINS = None
- فهرست افزونهها برای بارگیری. بخش افزونهها <#plugins> را ببینید.
- PLUGIN_PATHS = []
- فهرستی از دایرکتوریها برای جستجوی افزونهها. بخش افزونهها <#plugins> را ببینید.
- SITENAME = 'A Pelican Blog'
- نام وبسایت شما
- SITEURL
- نشانی اینترنتی پایه (Base URL) وبسایت شما. بهطور پیشفرض تعریف نشده است، بنابراین بهتر است مقدار SITEURL خود را تعیین کنید؛ در غیر این صورت فیدها با نشانیهای اینترنتی با ساختار صحیح تولید نخواهند شد. اگر سایت شما از طریق HTTPS در دسترس است، این تنظیم باید با https:// آغاز شود — در غیر این صورت از http:// استفاده کنید. سپس دامنهٔ خود را بدون ممیز انتهایی به آن اضافه کنید. مثال: SITEURL = 'https://example.com'
- STATIC_PATHS = ['images']
- فهرستی از دایرکتوریها (نسبت به PATH) برای جستجوی فایلهای ایستا (static). چنین فایلهایی بدون اعمال هیچ تغییری در دایرکتوری خروجی کپی خواهند شد. مقالهها، برگهها و سایر فایلهای مبدأ محتوا معمولاً نادیده گرفته میشوند، بنابراین قرار گرفتن یک دایرکتوری هم در اینجا و هم در PAGE_PATHS یا ARTICLE_PATHS بلامانع است. تنظیمات پیشفرض Pelican دایرکتوری "images" را در اینجا قرار میدهد.
- STATIC_EXCLUDES = []
- فهرستی از دایرکتوریها برای مستثنی کردن هنگام جستجوی فایلهای ایستا.
- STATIC_EXCLUDE_SOURCES = True
- اگر روی False تنظیم شود، فایلهای مبدأ محتوا هنگام کپی فایلهای پیدا شده در STATIC_PATHS نادیده گرفته نخواهند شد. این تنظیم برای حفظ سازگاری عقروعرو با نسخههای قبل از 3.5 نرمافزار Pelican است. این گزینه هیچ اثری نخواهد داشت مگر اینکه STATIC_PATHS شامل دایرکتوریای باشد که در ARTICLE_PATHS یا PAGE_PATHS نیز وجود دارد. اگر در تلاش برای انتشار فایلهای مبدأ وبسایت خود هستید، استفاده از تنظیم OUTPUT_SOURCES را مد نظر قرار دهید.
- STATIC_CREATE_LINKS = False
- ایجاد پیوند به جای کپی کردن فایلها. اگر دایرکتوریهای محتوا و خروجی روی یک دستگاه فیزیکی مشترک قرار داشته باشند، پیوندهای سخت (hard links) ایجاد میشوند. در صورتی که دایرکتوری خروجی روی یک سیستمفایل دیگر باشد، پیوندهای نمادین (symbolic links) جایگزین خواهند شد. در صورت ایجاد پیوندهای نمادین، فراموش نکنید که هنگام بارگذاری سایت خود، گزینهٔ -L یا --copy-links را به دستور rsync اضافه کنید.
- STATIC_CHECK_IF_MODIFIED = False
- اگر روی True تنظیم شود و مقدار STATIC_CREATE_LINKS برابر با False باشد، زمان تغییر (mtime) فایلهای محتوا و خروجی مقایسه شده و فقط فایلهای محتوایی که جدیدتر از فایلهای خروجی موجود باشند کپی خواهند شد.
- TYPOGRIFY = False
- در صورت تنظیم روی True، چندین بهبود تایپوگرافی از طریق کتابخانهٔ Typogrify https://pypi.org/project/typogrify در HTML تولیدشده اعمال خواهد شد؛ این کتابخانه از این طریق قابل نصب است: python -m pip install typogrify
- TYPOGRIFY_IGNORE_TAGS = []
- فهرستی از برچسبها که Typogrify باید آنها را نادیده بگیرد. بهطور پیشفرض، Typogrify برچسبهای pre و code را نادیده میگیرد. این ویژگی نیازمند نصب بودن Typogrify نسخهٔ 2.0.4 یا بالاتر است.
- TYPOGRIFY_OMIT_FILTERS = []
- فهرستی از فیلترهای Typogrify برای نادیده گرفتن. مقادیر مجاز عبارتند از: 'amp'، 'smartypants'، 'caps'، 'initial_quotes'، 'widont'. بهطور پیشفرض هیچ فیلتری نادیده گرفته نمیشود (به عبارت دیگر، تمام فیلترها اعمال میشوند). این تنظیم نیازمند نصب بودن Typogrify نسخهٔ 2.1.0 یا بالاتر است.
- TYPOGRIFY_DASHES = 'default'
- این تنظیم نحوهٔ پیکربندی فیلتر Smartypants توسط Typogrify را برای تفسیر چندین نویسهٔ خط تیره/خط پیوند/منفی (dash/hyphen/minus) کنترل میکند. یک نویسهٔ خط تیره اسکی منفرد (-) همیشه بهصورت یک خط پیوند (hyphen) نمایش داده میشود. تنظیم default خط تیرههای کوتاه (en-dash) را مدیریت نمیکند و خط پیوندهای دوگانه را به خط تیرههای بلند (em-dash) تبدیل میکند. تنظیم oldschool با مشاهدهٔ دو (--) و سه (---) نویسهٔ خط پیوند، بهترتیب خط تیرهٔ کوتاه (en-dash) و خط تیرهٔ بلند (em-dash) تولید میکند. تنظیم oldschool_inverted دو خط پیوند را به یک خط تیرهٔ بلند و سه خط پیوند را به یک خط تیرهٔ کوتاه تبدیل میکند.
- SUMMARY_MAX_LENGTH = 50
- هنگام ایجاد یک خلاصهٔ کوتاه برای یک مقاله، این مقدار طول پیشفرض (بر حسب کلمه) متن ایجادشده خواهد بود. این ویژگی تنها زمانی اعمال میشود که در محتوای شما خلاصهای بهطور جداگانه مشخص نشده باشد. تنظیم این گزینه روی None باعث میشود که خلاصه رونوشت دقیقی از محتوای اصلی باشد.
- SUMMARY_END_SUFFIX = '…'
- هنگام ایجاد یک خلاصه کوتاه از مقاله، اگر متن حاصل برای مطابقت با طول واژگان مورد نیاز کوتاه شود، این مقدار بهعنوان پسوند کوتاهسازی استفاده خواهد شد.
- WITH_FUTURE_DATES = True
- در صورت غیرفعال بودن، محتوای دارای تاریخهای مربوط به آینده وضعیت پیشفرض draft را دریافت میکند. برای نکات بیشتر به بخش Reading only modified content مراجعه کنید.
- INTRASITE_LINK_REGEX = '[{|](?P<what>.*?)[|}]'
- عبارت باقاعدهای که برای تجزیه پیوندهای داخلی استفاده میشود. نحو (syntax) پیشفرض هنگام پیوند به فایلهای داخلی، برچسبها و غیره این است که شناسه، مثلاً filename، درون {} یا || محصور شود. شناسه بین { و } در گروه ضبطکننده (capturing group) what قرار میگیرد. برای جزئیات به بخش Linking to internal content <#ref-linking-to-internal-content> مراجعه کنید.
- PYGMENTS_RST_OPTIONS = []
- فهرستی از تنظیمات پیشفرض Pygments برای بلوکهای کد reStructuredText شما. برای دیدن فهرستی از گزینههای پشتیبانیشده به بخش Syntax highlighting <#internal-pygments-options> مراجعه کنید.
- CACHE_CONTENT = False
- در صورت تنظیم روی True، محتوا در حافظههای نهان ذخیره میشود. برای جزئیات درباره نهانسازی به بخش Reading only modified content مراجعه کنید.
- CONTENT_CACHING_LAYER = 'reader'
- اگر روی 'reader' تنظیم شود، فقط محتوای خام و فراداده بازگرداندهشده توسط readerها ذخیره میشود. اگر روی 'generator' تنظیم شود، اشیاء محتوای پردازششده ذخیره خواهند شد.
- CACHE_PATH = 'cache'
- دایرکتوریای که فایلهای حافظه نهان در آن ذخیره میشوند.
- GZIP_CACHE = True
- اگر True باشد، از gzip برای فشردهسازی یا استخراج فایلهای حافظه نهان استفاده میشود.
- CHECK_MODIFIED_METHOD = 'mtime'
- چگونگی بررسی فایلها از نظر تغییرات را کنترل میکند.
- اگر روی 'mtime' تنظیم شود، زمان آخرین تغییر فایل بررسی میشود.
- اگر روی نام تابعی ارائهشده توسط ماژول hashlib تنظیم شود، مانند 'md5'، هش فایل بررسی میشود.
- LOAD_CONTENT_CACHE = False
- اگر True باشد، محتوای تغییرنیافته را از حافظههای نهان بارگیری میکند.
- FORMATTED_FIELDS = ['summary']
- فهرستی از فیلدهای فراداده حاوی محتوای reST/Markdown که باید تجزیه و به HTML ترجمه شوند.
- PORT = 8000
- پورت TCP برای ارائه محتوا از پوشه خروجی از طریق HTTP، زمانی که pelican با --listen اجرا میشود.
- BIND = ''
- آدرس IP که سرور HTTP به آن متصل (bind) میشود.
تنظیمات URL (URL settings)
نخستین نکته این است که در حال حاضر دو روش پشتیبانیشده برای ساخت URL وجود دارد: relative (نسبی) و absolute (مطلق). نشانیهای نسبی هنگام آزمایش محلی مفید هستند و نشانیهای مطلق قابلاطمینانتر بوده و هنگام انتشار بیشترین کاربرد را دارند. یکی از روشها برای پشتیبانی از هر دو، داشتن یک فایل پیکربندی Pelican برای توسعه محلی و فایلی دیگر برای انتشار است. برای مشاهده نمونهای از این راهاندازی، از اسکریپت pelican-quickstart مطابق با توضیحات بخش Installation <> استفاده کنید که دو فایل پیکربندی جداگانه بهترتیب برای توسعه محلی و انتشار تولید خواهد کرد.
میتوانید نشانیهای URL و مکانهایی که فایلها ذخیره میشوند را سفارشی کنید. متغیرهای *_URL و *_SAVE_AS از رشتههای قالببندی (format strings) پایتون استفاده میکنند. این متغیرها به شما امکان میدهند تا مقالههای خود را در مکانی مانند {slug}/index.html قرار دهید و برای داشتن نشانیهای تمیز، پیوند آنها را بهصورت {slug} بنویسید (مثال زیر را ببینید). این تنظیمات انعطافپذیری لازم را برای قرار دادن مقالهها و صفحهها در هر جایی که میخواهید فراهم میکنند.
نکته:
اگر به این سطح از انعطاف نیازی ندارید و ترجیح میدهید مسیرهای خروجی تولیدشده دقیقاً ساختار درختی مسیرهای فایلسیستم محتوای مبدأ شما را بازتاب دهند، تنظیمات زیر را امتحان کنید:
PATH_METADATA = '(?P<path_no_ext>.*)\..*'
ARTICLE_URL = ARTICLE_SAVE_AS = PAGE_URL = PAGE_SAVE_AS = '{path_no_ext}.html'
در غیر این صورت، میتوانید از ویژگیهای فرادادهای گوناگون فایل درون تنظیمات مربوط به URL استفاده کنید:
- slug
- date
- lang
- author
- category
نمونه کاربرد:
ARTICLE_URL = 'posts/{date:%Y}/{date:%b}/{date:%d}/{slug}/'
ARTICLE_SAVE_AS = 'posts/{date:%Y}/{date:%b}/{date:%d}/{slug}/index.html'
PAGE_URL = 'pages/{slug}/'
PAGE_SAVE_AS = 'pages/{slug}/index.html'
این کار مقالههای شما را در مکانی شبیه به /posts/2011/Aug/07/sample-post/index.html و صفحههای شما را در /pages/about/index.html ذخیره میکند، و آنها را بهترتیب در نشانیهای /posts/2011/Aug/07/sample-post/ و /pages/about/ در دسترس قرار میدهد.
نکته:
- RELATIVE_URLS = False
- مشخص میکند که آیا Pelican باید از URLهای نسبی به سند استفاده کند یا خیر. این مورد را تنها هنگام توسعه/آزمایش و تنها در صورتی که تأثیر آن بر پیوندها/خوراکها را بهطور کامل درک کردهاید روی True تنظیم کنید.
- ARTICLE_URL = '{slug}.html'
- نشانی اینترنتی (URL) برای ارجاع به یک مقاله.
- ARTICLE_SAVE_AS = '{slug}.html'
- مکانی که در آن یک مقاله ذخیره خواهد شد.
- ARTICLE_LANG_URL = '{slug}-{lang}.html'
- نشانی اینترنتی (URL) برای ارجاع به مقالهای که از زبان پیشفرض استفاده نمیکند.
- ARTICLE_LANG_SAVE_AS = '{slug}-{lang}.html'
- مکانی که در آن مقالهای که از زبان پیشفرض استفاده نمیکند ذخیره خواهد شد.
- DRAFT_SAVE_AS = 'drafts/{slug}.html'
- مکانی که پیشنویس مقاله در آن ذخیره خواهد شد.
- DRAFT_LANG_URL = 'drafts/{slug}-{lang}.html'
- نشانی URL برای ارجاع به پیشنویس مقالهای که از زبان پیشفرض استفاده نمیکند.
- DRAFT_LANG_SAVE_AS = 'drafts/{slug}-{lang}.html'
- مکانی که پیشنویس مقالهای که از زبان پیشفرض استفاده نمیکند در آن ذخیره خواهد شد.
- PAGE_URL = 'pages/{slug}.html'
- نشانی URL مورد استفاده برای پیوند به یک برگه.
- PAGE_SAVE_AS = 'pages/{slug}.html'
- مکانی که برگه در آن ذخیره خواهد شد. این مقدار باید با PAGE_URL یکسان باشد یا اینکه لازم است از rewrite در پیکربندی سرور خود استفاده کنید.
- PAGE_LANG_URL = 'pages/{slug}-{lang}.html'
- نشانی URL مورد استفاده برای پیوند به برگهای که از زبان پیشفرض استفاده نمیکند.
- PAGE_LANG_SAVE_AS = 'pages/{slug}-{lang}.html'
- مکانی که برگهای که از زبان پیشفرض استفاده نمیکند در آن ذخیره خواهد شد.
- DRAFT_PAGE_URL = 'drafts/pages/{slug}.html'
- نشانی URL مورد استفاده برای پیوند به پیشنویس یک برگه.
- DRAFT_PAGE_SAVE_AS = 'drafts/pages/{slug}.html'
- مکان واقعی ذخیرهسازی پیشنویس یک برگه.
- DRAFT_PAGE_LANG_URL = 'drafts/pages/{slug}-{lang}.html'
- نشانی URL مورد استفاده برای پیوند به پیشنویس برگهای که از زبان پیشفرض استفاده نمیکند.
- DRAFT_PAGE_LANG_SAVE_AS = 'drafts/pages/{slug}-{lang}.html'
- مکان واقعی ذخیرهسازی پیشنویس برگهای که از زبان پیشفرض استفاده نمیکند.
- AUTHOR_URL = 'author/{slug}.html'
- نشانی URL مورد استفاده برای یک نویسنده.
- AUTHOR_SAVE_AS = 'author/{slug}.html'
- مکانی برای ذخیرهسازی صفحه نویسنده.
- CATEGORY_URL = 'category/{slug}.html'
- نشانی URL مورد استفاده برای یک دستهبندی.
- CATEGORY_SAVE_AS = 'category/{slug}.html'
- مکانی برای ذخیرهسازی یک دستهبندی.
- TAG_URL = 'tag/{slug}.html'
- نشانی URL مورد استفاده برای یک برچسب.
- TAG_SAVE_AS = 'tag/{slug}.html'
- مکانی برای ذخیرهسازی برگه برچسب.
نکته:
Pelican میتواند به صورت اختیاری بایگانیهای سالانه، ماهانه و روزانه از پستهای شما ایجاد کند. این بایگانیهای ثانویه به طور پیشفرض غیرفعال هستند، اما در صورتی که رشتههای قالببندی (format strings) را برای تنظیمات _SAVE_AS مربوطهشان مشخص کنید، به طور خودکار فعال میشوند. بایگانیهای دورهای به صورت شهودی با مدل سلسلهمراتبی نشانیهای اینترنتی سازگار هستند و میتوانند پیمایش در میان پستهایی را که در طول زمان نوشتهاید برای خوانندگان آسانتر کنند.
نمونه کاربرد:
YEAR_ARCHIVE_SAVE_AS = 'posts/{date:%Y}/index.html'
YEAR_ARCHIVE_URL = 'posts/{date:%Y}/'
MONTH_ARCHIVE_SAVE_AS = 'posts/{date:%Y}/{date:%b}/index.html'
MONTH_ARCHIVE_URL = 'posts/{date:%Y}/{date:%b}/'
با این تنظیمات، Pelican یک بایگانی از تمامی پستهای سال شما در (برای نمونه) posts/2011/index.html و یک بایگانی از تمامی پستهای ماه در posts/2011/Aug/index.html ایجاد خواهد کرد. این بایگانیها به ترتیب از طریق نشانیهای posts/2011/ و posts/2011/Aug/ قابل دسترسی خواهند بود.
نکته:
- YEAR_ARCHIVE_SAVE_AS = ''
- مکانی برای ذخیره بایگانیهای سالانه پستهای شما.
- YEAR_ARCHIVE_URL = ''
- نشانی URL مورد استفاده برای بایگانیهای سالانه پستهای شما. در صورت فعالسازی بایگانیهای سالانه، باید این گزینه را تنظیم کنید.
- MONTH_ARCHIVE_SAVE_AS = ''
- مکانی برای ذخیره بایگانیهای ماهانه پستهای شما.
- MONTH_ARCHIVE_URL = ''
- نشانی URL مورد استفاده برای بایگانیهای ماهانه پستهای شما. در صورت فعالسازی بایگانیهای ماهانه، باید این گزینه را تنظیم کنید.
- DAY_ARCHIVE_SAVE_AS = ''
- مکانی برای ذخیره بایگانیهای روزانه پستهای شما.
- DAY_ARCHIVE_URL = ''
- نشانی URL مورد استفاده برای بایگانیهای روزانه پستهای شما. در صورت فعالسازی بایگانیهای روزانه، باید این گزینه را تنظیم کنید.
DIRECT_TEMPLATES کمی متفاوت از موارد ذکر شده در بالا عمل میکنند. فقط تنظیمات _SAVE_AS موجود هستند، اما این قابلیت برای هر قالب مستقیمی در دسترس است.
- ARCHIVES_SAVE_AS = 'archives.html'
- مکانی برای ذخیره برگه بایگانی مقالات.
- AUTHORS_SAVE_AS = 'authors.html'
- مکانی برای ذخیره فهرست نویسندگان.
- CATEGORIES_SAVE_AS = 'categories.html'
- مکانی برای ذخیره فهرست دستهبندیها.
- TAGS_SAVE_AS = 'tags.html'
- مکانی برای ذخیره فهرست برچسبها.
- INDEX_SAVE_AS = 'index.html'
- مکانی برای ذخیره فهرست تمامی مقالات.
نشانیهای URL برای برگههای قالب مستقیم به پوسته وابسته هستند. برخی پوستهها از تنظیم *_URL مربوطه به عنوان رشته استفاده میکنند، در حالی که برخی دیگر آنها را بهصورت سختکدشده قرار میدهند: 'archives.html'، 'authors.html'، 'categories.html'، 'tags.html'.
- SLUGIFY_USE_UNICODE = False
- اجازه دادن به نویسههای یونیکد در اسلاگها. مقدار را روی True قرار دهید تا نویسههای یونیکد در اسلاگهای خودکار حفظ شوند. در غیر این صورت، نویسههای یونیکد با معادلهای ASCII جایگزین خواهند شد.
- SLUGIFY_PRESERVE_CASE = False
- حفظ حروف بزرگ در اسلاگها. مقدار را روی True قرار دهید تا حروف بزرگ برگرفته از SLUGIFY_SOURCE همانگونه که هستند حفظ شوند.
- SLUG_REGEX_SUBSTITUTIONS = [
- (r'[^\\w\\s-]', ''), # remove non-alphabetical/whitespace/'-' chars
- (r'(?u)\\A\\s*', ''), # strip leading whitespace
- (r'(?u)\\s*\\Z', ''), # strip trailing whitespace
- (r'[-\\s]+', '-'), # reduce multiple whitespace or '-' to single '-'
- ]
- جایگزینیهای عبارت باقاعده (Regex) هنگام تولید اسلاگ مقالهها و صفحهها. به صورت فهرستی از جفتهای (from, to) مشخص میشود که به ترتیب و بدون در نظر گرفتن بزرگی و کوچکی حروف اعمال میشوند. جایگزینیهای پیشفرض، نویسههای غیرحرفی-عددی را حذف کرده و فاصلههای خالی میانی را به خط تیره تبدیل میکنند. گذشته از این جایگزینیها، اسلاگها همیشه به حروف کوچک ASCII تبدیل شده و فاصلههای خالی ابتدا و انتهای آنها حذف میشوند. برای سازگاری رو به عقب با URLهای موجود مفید است.
- AUTHOR_REGEX_SUBSTITUTIONS = SLUG_REGEX_SUBSTITUTIONS
- جایگزینیهای عبارت باقاعده برای اسلاگهای نویسنده. پیشفرض آن SLUG_REGEX_SUBSTITUTIONS است.
- CATEGORY_REGEX_SUBSTITUTIONS = SLUG_REGEX_SUBSTITUTIONS
- جایگزینیهای عبارت باقاعده برای اسلاگهای دستهبندی. پیشفرض آن SLUG_REGEX_SUBSTITUTIONS است.
- TAG_REGEX_SUBSTITUTIONS = SLUG_REGEX_SUBSTITUTIONS
- جایگزینیهای عبارت باقاعده برای اسلاگهای برچسب. پیشفرض آن SLUG_REGEX_SUBSTITUTIONS است.
زمان و تاریخ (Time and Date)
- TIMEZONE
- منطقهٔ
زمانی مورد
استفاده در
اطلاعات
تاریخ،
برای تولید
خوراکهای
Atom و RSS.
اگر هیچ منطقهٔ زمانی مشخص نشده باشد، UTC در نظر گرفته میشود. این بدان معناست که در صورت یکی نبودن تنظیمات محلی (locale) شما با UTC، خوراکهای تولیدشدهٔ Atom و RSS حاوی اطلاعات تاریخ نادرستی خواهند بود.
در صورتی که این تنظیم مشخص نشده باشد Pelican هشداری صادر میکند، زیرا در نسخههای پیشین اجباری نبوده است.
برای دسترسی به فهرست مقادیر معتبر منطقهٔ زمانی، به صفحهٔ ویکیپدیا در https://en.wikipedia.org/wiki/List_of_tz_database_time_zones نگاهی بیندازید.
- DEFAULT_DATE = None
- تاریخ پیشفرضی که میخواهید استفاده کنید. اگر روی 'fs' تنظیم شود، در صورتی که Pelican نتواند اطلاعات تاریخ را از فراداده دریافت کند، از اطلاعات مهر زمانی فایلسیستم (mtime) استفاده خواهد کرد. در صورت تعیین هر رشتهٔ متنی دیگر، با همان روش فرادادهٔ مقاله تجزیه خواهد شد. در صورت تنظیم روی یک شیء تاپل (tuple)، شیء datetime پیشفرض با ارسال تاپل به سازندهٔ datetime.datetime ایجاد خواهد شد.
- DEFAULT_DATE_FORMAT = '%a %d %B %Y'
- قالب تاریخ پیشفرضی که میخواهید استفاده کنید.
- DATE_FORMATS = {}
- اگر چند
زبان را
مدیریت
میکنید،
میتوانید
قالببندی
تاریخ را در
اینجا
تنظیم کنید.
اگر DATE_FORMATS تنظیم نشده باشد، Pelican به DEFAULT_DATE_FORMAT رجوع خواهد کرد. اگر نیاز به پشتیبانی از چند زبان با قالبهای تاریخ متفاوت دارید، میتوانید دیکشنری DATE_FORMATS را با استفاده از نام زبان (فرادادهٔ lang در محتوای مطلب شما) به عنوان کلید تنظیم نمایید.
علاوه بر کدهای قالب استاندارد C89 strftime که در مستندات datetime پایتون در https://docs.python.org/3/library/datetime.html#strftime-and-strptime-behavior فهرست شدهاند، میتوانید از نویسهٔ - بین % و نویسهٔ قالب برای حذف صفرهای آغازین استفاده کنید. برای نمونه، %d/%m/%Y خروجی 01/01/2014 را تولید میکند، در حالی که %-d/%-m/%Y به 1/1/2014 منجر میشود.
DATE_FORMATS = {
'en': '%a, %d %b %Y',
'jp': '%Y-%m-%d(%a)',
}
همچنین میتوان با استفاده از یک تاپل (locale, format) به عنوان مقدار دیکشنری، تنظیمات محلی متفاوتی را برای هر زبان تعیین کرد که تنظیم LOCALE را بازنویسی میکند:
# On Unix/Linux
DATE_FORMATS = {
'en': ('en_US','%a, %d %b %Y'),
'jp': ('ja_JP','%Y-%m-%d(%a)'),
}
# On Windows
DATE_FORMATS = {
'en': ('usa','%a, %d %b %Y'),
'jp': ('jpn','%Y-%m-%d(%a)'),
}
- LOCALE
- تغییر
تنظیمات
محلی (locale) [1].
میتوان
فهرستی از
localeها یا یک
رشتهٔ
منفرد
نمایانگر
یک locale را در
اینجا وارد
کرد. هنگام
ارائهٔ
فهرست،
همهٔ localeها تا
زمانی که
یکی کار
کند،
امتحان
خواهند شد.
میتوانید locale را برای کنترل بیشتر روی قالب تاریخ تنظیم کنید:
LOCALE = ('usa', 'jpn', # On Windows
'en_US', 'ja_JP' # On Unix/Linux
)
برای دسترسی به فهرست localeهای در دسترس به locales on Windows در https://www.microsoft.com/en-us/download/details.aspx?id=55979 مراجعه کنید، یا در Unix/Linux از دستور locale -a استفاده نمایید؛ برای اطلاعات بیشتر به صفحهٔ راهنمای locale(1) در https://linux.die.net/man/1/locale نگاهی بیندازید.
- [1]
- پیشفرض، تنظیمات محلی (locale) سیستم است..SS صفحههای قالب (Template pages)
- TEMPLATE_PAGES = None
- نگاشتی
شامل
صفحههای
قالبی که
همراه با
نوشتههای
وبلاگ رندر
خواهند شد.
اگر میخواهید علاوه بر نوشتههای وبلاگ خود صفحههای سفارشی ایجاد کنید، میتوانید هر فایل قالب Jinja2 را با مسیری که به فایل اشاره میکند و مسیر مقصد برای فایل تولیدشده مشخص نمایید.
برای نمونه، اگر وبلاگی با سه صفحه ایستا دارید — فهرستی از کتابها، رزومه شما و یک صفحه تماس — میتوانید چنین تنظیمی داشته باشید:
TEMPLATE_PAGES = {'src/books.html': 'dest/books.html',
'src/resume.html': 'dest/resume.html',
'src/contact.html': 'dest/contact.html'}
- TEMPLATE_EXTENSIONS = ['.html']
- پسوندهایی که هنگام جستجوی فایلهای قالب بر اساس نام قالبها استفاده میشوند.
- DIRECT_TEMPLATES = ['index', 'authors', 'categories', 'tags', 'archives']
- فهرستی از
قالبهایی
که
مستقیماً
برای رندر
محتوا
استفاده
میشوند.
معمولاً
قالبهای
مستقیم
برای ایجاد
صفحات
نمایه
(شاخص) برای
مجموعههای
محتوا
(مانند
صفحات
نمایه
دستهبندی
و برچسب) به
کار
میروند.
اگر
مجموعههای
نویسنده،
دستهبندی
و برچسب
نیاز
نیستند،
مقدار DIRECT_TEMPLATES = ['index',
'archives'] را تنظیم
کنید.
قالبهای DIRECT_TEMPLATES در مسیرهای نگهداریشده در THEME_TEMPLATES_OVERRIDES جستجو میشوند.
متاداده (Metadata)
- AUTHOR
- نویسنده پیشفرض (معمولاً نام شما).
- DEFAULT_METADATA = {}
- متاداده پیشفرضی که میخواهید برای همه مقالهها و صفحهها استفاده کنید.
- FILENAME_METADATA = r'(?P<date>\\d{4}-\\d{2}-\\d{2}).*'
- عبارت
باقاعدهای
(regexp) که برای
استخراج
متاداده از
نام فایل
استفاده
خواهد شد.
تمام
گروههای
نامگذاریشدهای
که مطابقت
داده شوند
در شیء
متاداده
مقداردهی
میشوند.
مقدار
پیشفرض
تنها تاریخ
را از نام
فایل
استخراج
میکند.
برای نمونه، جهت استخراج همزمان تاریخ و نامک (slug):
FILENAME_METADATA = r'(?P<date>\d{4}-\d{2}-\d{2})_(?P<slug>.*)'
همچنین SLUGIFY_SOURCE را ببینید.
- PATH_METADATA = ''
- مشابه FILENAME_METADATA، اما از مسیر کامل یک صفحه نسبت به دایرکتوری منبع محتوا پردازش میشود.
- EXTRA_PATH_METADATA = {}
- دیکشنریهای متاداده اضافی با کلید مسیر نسبی. برخلاف برخی دیگر از تنظیمات فایل در Pelican، مسیرهای نسبی نیازمند جداکنندههای پوشه مخصوص سیستمعامل (یعنی / در UNIX و \ در Windows) هستند. مسیرهای مشخصشده به یک دایرکتوری برای همه فایلهای زیر آن اعمال میشوند. در صورت بروز تعارض، خاصترین مسیر اولویت خواهد داشت.
نیازی نیست همه متادادهها در خود فایل منبع جاسازی شوند <#internal-metadata>. برای نمونه، پستهای وبلاگ اغلب طبق الگوی YYYY-MM-DD-SLUG.rst نامگذاری میشوند یا در دایرکتوریهای تودرتوی YYYY/MM/DD-SLUG قرار میگیرند. برای استخراج متاداده از نام فایل یا مسیر، FILENAME_METADATA یا PATH_METADATA را روی عبارتهای باقاعدهای تنظیم کنید که از شیوهنامگذاری گروهها در پایتون https://docs.python.org/3/library/re.html#regular-expression-syntax (?P<name>…) استفاده میکنند. اگر میخواهید متادادههای بیشتری پیوست کنید اما مایل نیستید آنها را در مسیر درج نمایید، میتوانید EXTRA_PATH_METADATA را تنظیم کنید:
EXTRA_PATH_METADATA = {
'relative/path/to/file-1': {
'key-1a': 'value-1a',
'key-1b': 'value-1b',
},
'relative/path/to/file-2': {
'key-2': 'value-2',
},
}
این کار میتواند روشی مناسب برای تغییر مکان نصب یک فایل خاص باشد:
# Take advantage of the following defaults
# STATIC_SAVE_AS = '{path}'
# STATIC_URL = '{path}'
STATIC_PATHS = [
'static/robots.txt',
]
EXTRA_PATH_METADATA = {
'static/robots.txt': {'path': 'robots.txt'},
}
بهطور پیشفرض، Pelican از خوراکهای Atom استفاده میکند. با این حال، در صورت تمایل امکان استفاده از خوراکهای RSS نیز وجود دارد.
Pelican خوراکهای دستهبندی و همچنین خوراکهایی برای تمامی مقالات شما تولید میکند. این ابزار بهطور پیشفرض خوراکی برای برچسبها تولید نمیکند، اما انجام این کار با استفاده از تنظیمات TAG_FEED_ATOM و TAG_FEED_RSS امکانپذیر است:
- FEED_DOMAIN = None، یعنی URL پایه "/" است
- دامنهای که به ابتدای URLهای خوراک افزوده میشود. از آنجا که URLهای خوراک همیشه باید مطلق (absolute) باشند، اکیداً توصیه میشود این مقدار تعریف شود (به عنوان مثال، "https://feeds.example.com"). اگر پیشتر SITEURL را به صراحت تعریف کردهاید (به بالا مراجعه کنید) و میخواهید از همان دامنه برای خوراکهای خود استفاده کنید، کافی است مقدار زیر را قرار دهید: FEED_DOMAIN = SITEURL.
- FEED_ATOM = None، یعنی بدون خوراک Atom
- محل ذخیره خوراک Atom.
- FEED_ATOM_URL = None
- URL نسبی خوراک Atom. در صورت تنظیم نشدن، از FEED_ATOM هم برای محل ذخیره و هم برای URL استفاده میشود.
- FEED_RSS = None، یعنی بدون RSS
- محل ذخیره خوراک RSS.
- FEED_RSS_URL = None
- URL نسبی خوراک RSS. در صورت تنظیم نشدن، از FEED_RSS هم برای محل ذخیره و هم برای URL استفاده میشود.
- FEED_ALL_ATOM = 'feeds/all.atom.xml'
- محل ذخیره خوراک Atom تمامی پستها: این خوراک دربرگیرنده تمامی پستها بدون در نظر گرفتن زبان آنها خواهد بود.
- FEED_ALL_ATOM_URL = None
- URL نسبی خوراک Atom تمامی پستها. در صورت تنظیم نشدن، از FEED_ALL_ATOM هم برای محل ذخیره و هم برای URL استفاده میشود.
- FEED_ALL_RSS = None، یعنی بدون RSS تمام پستها
- محل ذخیره خوراک RSS تمامی پستها: این خوراک دربرگیرنده تمامی پستها بدون در نظر گرفتن زبان آنها خواهد بود.
- FEED_ALL_RSS_URL = None
- URL نسبی خوراک RSS تمامی پستها. در صورت تنظیم نشدن، از FEED_ALL_RSS هم برای محل ذخیره و هم برای URL استفاده میشود.
- CATEGORY_FEED_ATOM = 'feeds/{slug}.atom.xml'
- محل ذخیره خوراکهای Atom دستهبندی. [2]
- CATEGORY_FEED_ATOM_URL = None
- URL نسبی خوراکهای Atom دستهبندی، شامل جاینگهدار {slug}. [2] در صورت تنظیم نشدن، از CATEGORY_FEED_ATOM هم برای محل ذخیره و هم برای URL استفاده میشود.
- CATEGORY_FEED_RSS = None، یعنی بدون RSS
- محل ذخیره خوراکهای RSS دستهبندی، شامل جاینگهدار {slug}. [2]
- CATEGORY_FEED_RSS_URL = None
- URL نسبی خوراکهای RSS دستهبندی، شامل جاینگهدار {slug}. [2] در صورت تنظیم نشدن، از CATEGORY_FEED_RSS هم برای محل ذخیره و هم برای URL استفاده میشود.
- AUTHOR_FEED_ATOM = 'feeds/{slug}.atom.xml'
- محل ذخیره خوراکهای Atom نویسنده. [2]
- AUTHOR_FEED_ATOM_URL = None
- URL نسبی خوراکهای Atom نویسنده، شامل جاینگهدار {slug}. [2] در صورت تنظیم نشدن، از AUTHOR_FEED_ATOM هم برای محل ذخیره و هم برای URL استفاده میشود.
- AUTHOR_FEED_RSS = 'feeds/{slug}.rss.xml'
- محل ذخیره خوراکهای RSS نویسنده. [2]
- AUTHOR_FEED_RSS_URL = None
- URL نسبی خوراکهای RSS نویسنده، شامل جاینگهدار {slug}. [2] در صورت تنظیم نشدن، از AUTHOR_FEED_RSS هم برای محل ذخیره و هم برای URL استفاده میشود.
- TAG_FEED_ATOM = None، یعنی بدون خوراک برچسب
- محل ذخیره خوراک Atom برچسب، شامل جاینگهدار {slug}. [2]
- TAG_FEED_ATOM_URL = None
- URL نسبی خوراک Atom برچسب، شامل جاینگهدار {slug}. [2]
- TAG_FEED_RSS = None، یعنی بدون خوراک برچسب RSS
- URL نسبی برای خروجی خوراک RSS برچسب، شامل جاینگهدار {slug}. در صورت تنظیم نشدن، از TAG_FEED_RSS هم برای محل ذخیره و هم برای URL استفاده میشود.
- FEED_MAX_ITEMS = 100
- حداکثر تعداد مجاز آیتمها در یک خوراک. تنظیم روی None باعث میشود که خوراک شامل تمامی مقالات باشد. در صورت مشخص نشدن، مقدار پیشفرض 100 است.
- RSS_FEED_SUMMARY_ONLY = True
- تنها خلاصههای آیتم در تگ description خوراکهای RSS گنجانده شوند. در صورت تنظیم روی False، کل محتوا به جای آن قرار خواهد گرفت. این تنظیم بر خوراکهای Atom تأثیری ندارد و تنها روی خوراکهای RSS اعمال میشود.
- FEED_APPEND_REF = False
- در صورت تنظیم روی True، مقدار ?ref=feed به منظور ردیابی ارجاعدهنده به پیوندهای موجود در خوراکهای تولیدشده افزوده خواهد شد.
اگر نمیخواهید برخی یا هیچیک از این خوراکها تولید شوند، متغیرهای بالا را روی None تنظیم کنید.
- [2]
- عبارت {slug} با
نام
دستهبندی /
نویسنده /
برچسب
جایگزین
میشود..SS
صفحهبندی
(Pagination)
رفتار پیشفرض Pelican این است که تمام عنوانهای مقالهها را همراه با توضیح کوتاهی در صفحه اصلی (index) فهرست کند. اگرچه این روش برای وبگاههای کوچک تا متوسط بهخوبی کار میکند، اما وبگاههایی با تعداد زیادی مقاله احتمالاً از صفحهبندی این فهرست بهرهمند خواهند شد.
میتوانید از تنظیمات زیر برای پیکربندی صفحهبندی استفاده کنید.
- DEFAULT_ORPHANS = 0
- حداقل تعداد مقالههای مجاز در آخرین صفحه. زمانی از این گزینه استفاده کنید که نمیخواهید صفحه آخر تنها شامل تعداد اندکی مقاله باشد.
- DEFAULT_PAGINATION = False
- حداکثر تعداد مقالهها برای قرارگیری در یک صفحه، بدون احتساب مقالههای تنها مانده (orphans). مقدار False برای غیرفعال کردن صفحهبندی است.
- PAGINATED_TEMPLATES = {'index': None, 'tag': None, 'category': None, 'author': None}
- قالبهایی که صفحهبندی باید روی آنها اعمال شود، و تعداد مقالهها برای قرارگیری در یک صفحه. اگر این مقدار None باشد، به DEFAULT_PAGINATION تغییر مییابد.
- PAGINATION_PATTERNS = (
- (1, '{name}{extension}', '{name}{extension}'),
- (2, '{name}{number}{extension}', '{name}{number}{extension}'),
- )
استفاده از الگوهای صفحهبندی (Using Pagination Patterns)
بهطور پیشفرض، صفحههای بعد از .../foo.html بهصورت .../foo2.html و غیره ایجاد میشوند. از تنظیم PAGINATION_PATTERNS میتوان برای تغییر این رفتار استفاده کرد. این تنظیم دنبالهای از سهتاییها را میپذیرد که هر سهتایی شامل موارد زیر است:
(minimum_page, page_url, page_save_as,)
برای page_url و page_save_as میتوانید از چندین متغیر استفاده کنید. {url} و {save_as} بهترتیب متناظر با مقادیر *_URL و *_SAVE_AS نوع صفحه مربوطه هستند (مانند ARTICLE_SAVE_AS). اگر {save_as} == foo/bar.html باشد، آنگاه {name} == foo/bar و {extension} == .html خواهد بود. مقدار {base_name} برابر با {name} است، با این تفاوت که پسوند پایانی /index را در صورت وجود حذف میکند. {number} برابر با شماره صفحه است.
بهعنوان مثال، اگر میخواهید صفحه اول بدون تغییر بماند، اما صفحههای بعدی در .../page/2/ و غیره قرار گیرند، میتوانید PAGINATION_PATTERNS را بهصورت زیر تنظیم کنید:
PAGINATION_PATTERNS = (
(1, '{url}', '{save_as}'),
(2, '{base_name}/page/{number}/', '{base_name}/page/{number}/index.html'),
)
اگر میخواهید الگویی بر آخرین صفحه در فهرست اعمال شود، از -1 بهعنوان مقدار minimum_page استفاده کنید:
(-1, '{base_name}/last/', '{base_name}/last/index.html'),
ترجمهها (Translations)
پروژه Pelican روشی برای ترجمه مقالهها ارائه میدهد. برای اطلاعات بیشتر بخش محتوا <> را ببینید.
- DEFAULT_LANG = 'en'
- زبان پیشفرضی که باید استفاده شود.
- ARTICLE_TRANSLATION_ID = 'slug'
- ویژگی(های) فراداده مورد استفاده برای تشخیص اینکه کدام مقالهها ترجمه یکدیگرند. میتواند یک رشته یا مجموعهای از رشتهها باشد. برای غیرفعال کردن شناسایی ترجمهها، آن را روی None یا False تنظیم کنید.
- PAGE_TRANSLATION_ID = 'slug'
- ویژگی(های) فراداده مورد استفاده برای تشخیص اینکه کدام صفحهها ترجمه یکدیگرند. میتواند یک رشته یا مجموعهای از رشتهها باشد. برای غیرفعال کردن شناسایی ترجمهها، آن را روی None یا False تنظیم کنید.
- TRANSLATION_FEED_ATOM = 'feeds/all-{lang}.atom.xml'
- محل ذخیره خوراک Atom برای ترجمهها. [3]
- TRANSLATION_FEED_ATOM_URL = None
- نشانی نسبی (URL) خوراک Atom برای ترجمهها، شامل جاینگهدار {lang}. [3] در صورت تنظیم نشدن، از TRANSLATION_FEED_ATOM هم برای محل ذخیره و هم برای URL استفاده میشود.
- TRANSLATION_FEED_RSS = None, i.e. no RSS
- محل قرار دادن خوراک RSS برای ترجمهها.
- TRANSLATION_FEED_RSS_URL = None
- نشانی نسبی (URL) خوراک RSS برای ترجمهها، شامل جاینگهدار {lang}. [3] در صورت تنظیم نشدن، از TRANSLATION_FEED_RSS هم برای محل ذخیره و هم برای URL استفاده میشود.
- [3]
- {lang} کد زبان است.SS مرتبسازی محتوا
- NEWEST_FIRST_ARCHIVES = True
- مرتبسازی آرشیوها بر اساس تاریخ از جدیدترین به قدیمیترین. (مقدار False: مقالهها بر اساس تاریخ بهگونهای مرتب میشوند که مقالههای قدیمیتر اول بیایند.)
- REVERSE_CATEGORY_ORDER = False
- معکوس کردن ترتیب دستهبندیها. (مقدار True: بر اساس ترتیب الفبایی معکوس فهرست میکند؛ مقدار پیشفرض بهصورت الفبایی است.)
- ARTICLE_ORDER_BY = 'reversed-date'
- نحوه مرتبسازی مقالهها (articles_page.object_list در قالب) را مشخص میکند. گزینههای معتبر عبارتند از: متاداده بهصورت یک رشته (استفاده از پیشوند reversed- برای معکوس کردن ترتیب مرتبسازی)، گزینه ویژه 'basename' که از نام پایه فایل (بدون مسیر) استفاده میکند، یا یک تابع سفارشی برای استخراج کلید مرتبسازی از مقالهها. استفاده از مقدار 'date' مقالهها را به ترتیب زمانی مرتب میکند، در حالی که مقدار پیشفرض، 'reversed-date'، مقالهها را بر اساس تاریخ به ترتیب معکوس (یعنی جدیدترین مقاله در ابتدا) مرتب خواهد کرد.
- PAGE_ORDER_BY = 'basename'
- نحوه مرتبسازی برگهها (متغیر pages در قالب) را مشخص میکند. گزینهها همانند ARTICLE_ORDER_BY هستند. مقدار پیشفرض، 'basename'، برگهها را بر اساس نام پایه آنها مرتب میکند.
تمها
ساخت تمهای Pelican در یک بخش اختصاصی بررسی شده است (نگاه کنید به تمها <#theming-pelican>). با این حال، در اینجا تنظیمات مربوط به تمها آمده است.
- THEME
- تم مورد استفاده برای تولید خروجی. میتواند یک مسیر نسبی یا مطلق به پوشه تم، یا نام یک تم پیشفرض یا تمی باشد که از طریق pelican-themes <> نصب شده است (پایین را ببینید).
- THEME_STATIC_DIR = 'theme'
- دایرکتوری مقصد در مسیر خروجی که در آن Pelican فایلهای جمعآوریشده از THEME_STATIC_PATHS را قرار میدهد. پیشفرض theme است.
- THEME_STATIC_PATHS = ['static']
- مسیرهای ایستای تم که میخواهید کپی شوند. مقدار پیشفرض static است، اما اگر تم شما مسیرهای ایستای دیگری دارد، میتوانید آنها را در اینجا قرار دهید. اگر فایلها یا دایرکتوریهایی با نام یکسان در مسیرهای تعریفشده در این تنظیمات وجود داشته باشند، بهطور متوالی بازنویسی خواهند شد.
- THEME_TEMPLATES_OVERRIDES = []
- فهرستی از
مسیرهایی
که
میخواهید
Jinja2 پیش از
جستجو در
دایرکتوری
templates/ تم،
برای یافتن
قالبها
جستجو کند.
این تنظیم
امکان
بازنویسی
فایلهای
قالب
اختصاصی تم
را بدون
نیاز به
فورک کردن
تم موجود
فراهم
میکند. Jinja2 به
ترتیب زیر
جستجو
میکند:
ابتدا
فایلهای
موجود در
THEME_TEMPLATES_OVERRIDES، سپس
دایرکتوری
templates/ تم.
همچنین میتوانید قالبهای تم را با استفاده از دستور {% extends %} و پیشوند !theme گسترش دهید، همانطور که در مثال زیر نشان داده شده است:
{% extends '!theme/article.html' %}
- CSS_FILE = 'main.css'
- مشخص کردن فایل CSS که میخواهید بارگذاری شود.
بهطور پیشفرض، دو تم در دسترس هستند. میتوانید آنها را با استفاده از تنظیم THEME یا با ارسال گزینه -t به دستور pelican مشخص کنید:
- notmyidea
- simple (مترادفی برای "متن ساده" :)
تعدادی تم دیگر در نشانی https://github.com/getpelican/pelican-themes در دسترس است. Pelican به همراه pelican-themes <>، یک اسکریپت کوچک برای مدیریت تمها، ارائه میشود.
شما میتوانید تم خود را چه با شروع از ابتدا و چه با تکثیر و ویرایش یک تم از پیشموجود ایجاد کنید. راهنمایی برای نحوه ساخت تم شما در <> موجود است.
در ادامه روشهای نمونه برای مشخص کردن تم دلخواه شما آمده است:
# مشخص کردن نام یک تم پیشساخته THEME = "notmyidea" # مشخص کردن نام تم نصبشده از طریق ابزار pelican-themes THEME = "chunk" # مشخص کردن تم سفارشی از طریق مسیر نسبی نسبت به فایل تنظیمات THEME = "themes/mycustomtheme" # مشخص کردن تم سفارشی از طریق مسیر مطلق THEME = "/home/myuser/projects/mysite/themes/mycustomtheme"
تم توکار simple را میتوان با استفاده از تنظیمات زیر سفارشیسازی کرد.
- STYLESHEET_URL
- نشانی URL شیوهنامهای (stylesheet) که باید استفاده شود.
تم توکار notmyidea میتواند از تنظیمات زیر بهخوبی بهره ببرد. شما نیز آزاد هستید که از آنها در تمهای خود استفاده کنید.
- SITESUBTITLE
- زیرعنوانی که در سربرگ نمایش داده میشود.
- DISQUS_SITENAME
- ابزار Pelican میتواند دیدگاههای Disqus را مدیریت کند. شناسه نام سایت Disqus را در اینجا مشخص کنید.
- GITHUB_URL
- نشانی GitHub شما (در صورت وجود). سپس از این اطلاعات برای ساخت روبان GitHub استفاده خواهد شد.
- ANALYTICS
- هرگونه اسکریپت آمارگیر دلخواه را در این تنظیم در publishconf.py قرار دهید. مثال:
ANALYTICS = """
<script src="/theme/js/primary-analytics.js"></script>
<script>
[ … in-line Javascript code for secondary analytics … ]
</script>
"""
- MENUITEMS
- فهرستی از تاپلهای (Title, URL) برای آیتمهای منوی اضافی جهت نمایش در ابتدای منوی اصلی.
- LINKS
- فهرستی از تاپلهای (Title, URL) برای پیوندهایی که در سربرگ نمایش داده میشوند.
- SOCIAL
- فهرستی از تاپلهای (Title, URL) برای نمایش در بخش "social".
- TWITTER_USERNAME
- امکان افزودن دکمهای به مقالهها جهت تشویق دیگران به ارسال توییت درباره آنها را فراهم میکند. در صورتی که میخواهید این دکمه نمایش داده شود، نام کاربری Twitter خود را اضافه کنید.
- LINKS_WIDGET_NAME
- امکان بازنویسی نام ابزارک پیوندها را فراهم میکند. در صورت عدم تعیین، بهطور پیشفرض "links" خواهد بود.
- SOCIAL_WIDGET_NAME
- امکان بازنویسی نام ابزارک "social" را فراهم میکند. در صورت عدم تعیین، بهطور پیشفرض "social" خواهد بود.
علاوه بر این، میتوانید با افزودن خط زیر به پیکربندی خود، از نسخه "wide" (عریض) تم notmyidea استفاده کنید:
CSS_FILE = "wide.css"
گاهی اوقات، ممکن است هنگام تولید سایت فهرست بلندی از هشدارها ظاهر شود. پیدا کردن پیام خطای معنادار در میان انبوهی از خروجیهای گزارش آزاردهنده میتواند بسیار دشوار باشد. برای پالایش پیامهای گزارش زاید، Pelican به همراه تنظیم LOG_FILTER عرضه میشود.
LOG_FILTER باید فهرستی از تاپلهای (level, msg) باشد که هر یک از سطح ثبت گزارش (تا حداکثر warning) و پیامی که باید نادیده گرفته شود تشکیل شده است. کافی است این فهرست را با پیامهای گزارشی که میخواهید پنهان شوند پر کنید تا پالایش شوند.
برای مثال:
import logging LOG_FILTER = [(logging.WARN, 'TAG_SAVE_AS is set to False')]
امکان پالایش پیامها با استفاده از یک الگو (template) نیز وجود دارد. برای به دست آوردن الگو، سورس کد را بررسی کنید.
برای مثال:
import logging LOG_FILTER = [(logging.WARN, 'Empty alt attribute for image %s in %s')]
هشدار:
نکته:
خواندن تنها محتوای تغییریافته (Reading only modified content)
برای افزایش سرعت فرایند ساخت، Pelican میتواند به صورت اختیاری فقط مقالهها و برگههای دارای محتوای تغییریافته را بخواند.
هنگامی که Pelican در شرف خواندن یک فایل منبع محتوا است:
- 1.
- اگر LOAD_CONTENT_CACHE برابر True باشد، اطلاعات هش یا زمان ویرایش فایل از ساخت قبلی از یک فایل حافظه موقت (cache) بارگذاری میشود. این فایلها در دایرکتوری CACHE_PATH ذخیره میشوند. اگر فایل رکوردی در فایل حافظه موقت نداشته باشد، طبق روال معمول خوانده میشود.
- 2.
- فایل بر اساس CHECK_MODIFIED_METHOD بررسی میشود:
- اگر روی 'mtime' تنظیم شده باشد، زمان ویرایش فایل بررسی میشود.
- اگر روی نام تابعی ارائهشده توسط ماژول hashlib تنظیم شده باشد، مانند 'md5'، هش فایل بررسی میشود.
- اگر روی هر چیز دیگری تنظیم شده باشد یا اطلاعات لازم درباره فایل در فایل حافظه موقت یافت نشود، محتوا طبق روال معمول خوانده میشود.
- 3.
- اگر فایل بدون تغییر تشخیص داده شود، دادههای محتوای ذخیرهشده در ساخت قبلیِ مربوط به آن فایل از حافظه موقت بارگذاری میشود و فایل خوانده نمیشود.
- 4.
- اگر فایل تغییریافته در نظر گرفته شود، فایل خوانده شده و در صورتی که CACHE_CONTENT برابر True باشد، اطلاعات ویرایش جدید و دادههای محتوا در حافظه موقت ذخیره میشوند.
اگر CONTENT_CACHING_LAYER روی 'reader' (پیشفرض) تنظیم شده باشد، محتوای خام و متادیتا (metadata) بازگرداندهشده توسط یک reader در حافظه موقت ذخیره میشوند. اگر این تنظیم به جای آن روی 'generator' تنظیم شود، شیء محتوای پردازششده در حافظه موقت ذخیره میشود. ذخیره شیء محتوای پردازششده در حافظه موقت ممکن است با افزونهها (به دلیل رد شدن برخی سیگنالهای مربوط به خواندن) و قابلیت WITH_FUTURE_DATES (زیرا وضعیت draft اشیاء محتوای ذخیرهشده در حافظه موقت به طور خودکار در گذر زمان تغییر نخواهد کرد) تداخل داشته باشد.
بررسی زمانهای ویرایش سریعتر از مقایسه هشهای فایل است، اما به اندازه آن قابل اعتماد نیست زیرا اطلاعات mtime ممکن است از بین برود، برای مثال هنگام کپی کردن فایلهای منبع محتوا با استفاده از دستورهای cp یا rsync بدون حالت حفظ mtime (که برای rsync با ارسال پرچم --archive فعال میشود).
فایلهای حافظه موقت از نوع pickle پایتون هستند، بنابراین ممکن است توسط نسخههای مختلف Python خوانا نباشند زیرا قالب pickle اغلب تغییر میکند. در صورت مواجهه با چنین خطایی، این خطا دریافت شده و فایل حافظه موقت به طور خودکار در قالب جدید بازسازی میشود. همچنین فایلهای حافظه موقت پس از تغییر تنظیم GZIP_CACHE بازسازی خواهند شد.
گزینه خط فرمان --ignore-cache زمانی مفید است که کل حافظه موقت نیاز به بازسازی داشته باشد، مانند اعمال تغییراتی در فایل تنظیمات که بر محتوای ذخیرهشده در حافظه موقت اثر میگذارد، یا صرفاً برای مقاصد اشکالزدایی. هنگامی که Pelican در حالت بارگذاری خودکار (autoreload) اجرا میشود، در صورتی که AUTORELOAD_IGNORE_CACHE برابر True باشد، ویرایش فایل تنظیمات باعث میشود حافظه موقت به طور خودکار نادیده گرفته شود.
توجه داشته باشید که حتی هنگام استفاده از محتوای حافظه موقت، تمام خروجی همیشه نوشته میشود، بنابراین زمانهای ویرایش فایلهای *.html تولیدشده همیشه تغییر خواهند کرد. از این رو، بارگذاری مبتنی بر rsync میتواند از گزینه --checksum بهرهمند شود..SS تنظیمات نمونه (Example settings)
AUTHOR = "Alexis Métaireau"
SITENAME = "Alexis' log"
SITESUBTITLE = "A personal blog."
SITEURL = "http://blog.notmyidea.org"
TIMEZONE = "Europe/Paris"
# can be useful in development, but set to False when you're ready to publish
RELATIVE_URLS = True
GITHUB_URL = "http://github.com/ametaireau/"
DISQUS_SITENAME = "blog-notmyidea"
REVERSE_CATEGORY_ORDER = True
LOCALE = "C"
DEFAULT_PAGINATION = 4
DEFAULT_DATE = (2012, 3, 2, 14, 1, 1)
FEED_ALL_RSS = "feeds/all.rss.xml"
CATEGORY_FEED_RSS = "feeds/{slug}.rss.xml"
LINKS = (
("Biologeek", "http://biologeek.org"),
("Filyb", "http://filyb.info/"),
("Libert-fr", "http://www.libert-fr.com"),
("N1k0", "http://prendreuncafe.com/blog/"),
("Tarek Ziadé", "http://ziade.org/blog"),
("Zubin Mithra", "http://zubin71.wordpress.com/"),
)
SOCIAL = (
("twitter", "http://twitter.com/ametaireau"),
("lastfm", "http://lastfm.com/user/akounet"),
("github", "http://github.com/ametaireau"),
)
# global metadata to all the contents
DEFAULT_METADATA = {"yeah": "it is"}
# path-specific metadata
EXTRA_PATH_METADATA = {
"extra/robots.txt": {"path": "robots.txt"},
}
# static paths will be copied without parsing their contents
STATIC_PATHS = [
"images",
"extra/robots.txt",
]
# custom page generated with a jinja2 template
TEMPLATE_PAGES = {"pages/jinja2_template.html": "jinja2_template.html"}
# there is no other HTML content
READERS = {"html": None}
# code blocks with line numbers
PYGMENTS_RST_OPTIONS = {"linenos": "table"}
# foobar will not be used, because it's not in caps. All configuration keys
# have to be in caps
foobar = "barbaz"
افزونهها (Plugins)
از نسخهٔ 3.0، Pelican از افزونهها پشتیبانی میکند. افزونهها راهکاری برای افزودن قابلیتها به Pelican بدون نیاز به تغییر مستقیم هستهٔ آن هستند.
نحوهٔ استفاده از افزونهها (How to use plugins)
از نسخهٔ 4.5، Pelican به ساختار جدیدی از افزونهها مبتنی بر بستههای فضاینام (namespace packages) مهاجرت کرد که بهسادگی از طریق Pip https://pip.pypa.io قابل نصب هستند. افزونههایی که از این ساختار پشتیبانی میکنند، ذیل بستهٔ فضاینام pelican.plugins نصب میشوند و میتوانند بهطور خودکار توسط Pelican شناسایی گردند. برای مشاهدهٔ فهرستی از افزونههای فضاینام نصبشده توسط Pip که در محیط شما فعال هستند، دستور زیر را اجرا کنید:
pelican-plugins
اگر تنظیم PLUGINS را روی مقدار پیشفرض (None) باقی بگذارید، Pelican بهطور خودکار افزونههای فضاینام را شناسایی و ثبت میکند. در مقابل، اگر تنظیم PLUGINS را به عنوان فهرستی از افزونهها مشخص کنید، این شناسایی خودکار غیرفعال خواهد شد. در این حالت، تنها افزونههایی که مشخص کردهاید ثبت میشوند و باید هر افزونهٔ فضاینام را نیز صراحتاً در فهرست قید نمایید.
در صورت استفاده از تنظیم PLUGINS، میتوانید افزونهها را به دو روش مشخص کنید. در روش نخست، افزونهها به عنوان فهرستی از رشتهها تعیین میشوند. افزونههای فضاینام را میتوان با نام کامل (pelican.plugins.myplugin) یا با نام کوتاه آنها (myplugin) مشخص کرد:
PLUGINS = ['package.myplugin',
'namespace_plugin1',
'pelican.plugins.namespace_plugin2']
به عنوان روش جایگزین، میتوانید آنها را در فایل تنظیمات خود وارد (import) کرده و ماژولها را ارسال کنید:
from package import myplugin from pelican.plugins import namespace_plugin1, namespace_plugin2 PLUGINS = [myplugin, namespace_plugin1, namespace_plugin2]
نکته:
اگر افزونههای شما در مسیری قابل وارد کردن (importable) قرار ندارند، میتوانید فهرستی از مسیرها را از طریق تنظیم PLUGIN_PATHS مشخص کنید. همانطور که در مثال زیر نشان داده شده است، مسیرها در فهرست PLUGIN_PATHS میتوانند به صورت مطلق یا نسبت به فایل تنظیمات، نسبی باشند:
PLUGIN_PATHS = ["plugins", "/srv/pelican/plugins"] PLUGINS = ["assets", "liquid_tags", "sitemap"]
پلاگینهای فضاینام (Namespace plugins) را میتوان در سازمان pelican-plugins https://github.com/pelican-plugins به عنوان مخزنهای جداگانه یافت. پلاگینهای موروثی (legacy) در مخزن pelican-plugins https://github.com/getpelican/pelican-plugins قرار دارند و به تدریج به نفع نسخههای فضاینام کنار گذاشته خواهند شد.
لطفاً توجه داشته باشید در حالی که ما تمام تلاش خود را برای بررسی و نگهداری این پلاگینها انجام میدهیم، اما آنها توسط جامعهٔ کاربران Pelican ارسال شدهاند و بنابراین ممکن است سطوح متفاوتی از پشتیبانی و سازگاری داشته باشند.
نحوه ساخت پلاگینها (How to create plugins)
پلاگینها بر اساس مفهوم سیگنالها کار میکنند. Pelican سیگنالها را ارسال میکند و پلاگینها در این سیگنالها مشترک میشوند. فهرست سیگنالهای موجود در بخش بعدی مستند شده است.
تنها قانونی که باید برای پلاگینها رعایت شود، تعریف یک شیء فراخوانیپذیر (callable) به نام register است که در آن سیگنالها را به منطق پلاگین خود متصل میکنید. بیایید یک مثال ساده را در نظر بگیریم:
import logging
from pelican import signals
log = logging.getLogger(__name__)
def test(sender):
log.debug(""%s initialized !!", sender)
def register():
signals.initialized.connect(test)
نکته:
اگر چندین پلاگین به یک سیگنال متصل شوند، پلاگینها به ترتیبی که ثبت شدهاند فراخوانی خواهند شد. هنگامی که تنظیمات PLUGINS تعریف شده باشد، ترتیب فراخوانی پلاگینها همان ترتیبی خواهد بود که در تنظیمات PLUGINS فهرست شدهاند. اگر به پلاگینهای فضاینامِ شناساییشده به صورت خودکار تکیه میکنید و تنظیم PLUGINS را تعریف نکردهاید، پلاگینها به همان ترتیبی که شناسایی میشوند فراخوانی خواهند شد (همان ترتیبی که در خروجی دستور pelican-plugins فهرست شده است). اگر میخواهید ترتیب را به صورت صریح مشخص کنید، شناسایی خودکار را با تعریف PLUGINS با ترتیب دلخواه غیرفعال کنید.
ساختار پلاگینهای فضاینام (Namespace plugin structure)
پلاگینهای فضاینام برای اینکه به درستی کار کنند باید از ساختار مشخصی پیروی کنند. آنها باید قابل نصب باشند (یعنی شامل setup.py یا معادل آن باشند) و ساختار پوشهای به صورت زیر داشته باشند:
myplugin ├── pelican │ └── plugins │ └── myplugin │ ├── __init__.py │ └── ... ├── ... └── setup.py
بسیار حیاتی است که پوشهٔ pelican یا pelican/plugins حاوی فایل __init__.py نباشد. در واقع، برای جلوگیری از هرگونه مشکل، بهتر است این پوشهها به جز پوشههای فهرستشده در ساختار بالا خالی باشند و فایلهای مربوط به پلاگین خود را صرفاً در پوشهٔ pelican/plugins/myplugin نگه دارید.
برای راهاندازی آسان ساختار مناسب، یک قالب cookiecutter برای پلاگینها https://github.com/getpelican/cookiecutter-pelican-plugin ارائه شده است. برای دستورالعملهای نحوه استفاده از آن، به فایل README آن پروژه مراجعه کنید.
فهرست سیگنالها (List of signals)
در اینجا فهرست سیگنالهایی که در حال حاضر پیادهسازی شدهاند آمده است:
| سیگنال | آرگومانها | توضیحات |
| initialized | pelican object | |
| finalized | pelican object | پس از اجرای همهٔ generatorها و درست پیش از خروج pelican فراخوانی میشود برای اقدامات پسپردازش سفارشی مفید است، مانند: - کوچکسازی (minify کردن) داراییهای js/css. - اطلاعرسانی/پینگ کردن موتورهای جستجو با sitemap بهروزشده. |
| generator_init | generator | در Generator.__init__ فراخوانی میشود |
| all_generators_finalized | generators | پس از اجرای همهٔ generatorها و پیش از نوشتن خروجی فراخوانی میشود |
| readers_init | readers | در Readers.__init__ فراخوانی میشود |
| article_generator_context | article_generator, metadata | |
| article_generator_preread | article_generator | پیش از خوانده شدن یک مقاله در ArticlesGenerator.generate_context فراخوانی میشود؛ اگر کد نیاز به انجام کاری پیش از تجزیهٔ هر مقاله دارد استفاده کنید |
| article_generator_init | article_generator | در ArticlesGenerator.__init__ فراخوانی میشود |
| article_generator_pretaxonomy | article_generator | پیش از ایجاد فهرست دستهبندیها و برچسبها فراخوانی میشود برای مواردی مانند تغییر فهرست مقالاتی که باید تولید شوند مفید است تا مقالات حذفشده در دستهبندیها یا برچسبها درز پیدا نکنند |
| article_generator_finalized | article_generator | در انتهای ArticlesGenerator.generate_context فراخوانی میشود |
| article_generator_write_article | article_generator, content | پیش از نوشتن هر مقاله فراخوانی میشود، مقاله به عنوان content ارسال میشود |
| article_writer_finalized | article_generator, writer | پس از اینکه تمام مقالات و صفحات مرتبط نوشته شدند فراخوانی میشود، اما پیش از بسته شدن article generator. |
| get_generators | pelican object | در Pelican.get_generator_classes فراخوانی میشود، میتواند یک Generator یا چندین generator را در یک چندتایی (tuple) یا در یک لیست بازگرداند. |
| get_writer | pelican object | در Pelican.get_writer فراخوانی میشود، میتواند یک Writer سفارشی بازگرداند. |
| page_generator_context | page_generator, metadata | |
| page_generator_preread | page_generator | پیش از خوانده شدن یک صفحه در PageGenerator.generate_context فراخوانی میشود؛ اگر کد نیاز به انجام کاری پیش از تجزیهٔ هر صفحه دارد استفاده کنید. |
| page_generator_init | page_generator | در PagesGenerator.__init__ فراخوانی میشود |
| page_generator_finalized | page_generator | در انتهای PagesGenerator.generate_context فراخوانی میشود |
| page_generator_write_page | page_generator, content | پیش از نوشتن هر صفحه فراخوانی میشود، صفحه به عنوان content ارسال میشود |
| page_writer_finalized | page_generator, writer | پس از اینکه تمام صفحات نوشته شدند فراخوانی میشود، اما پیش از بسته شدن page generator. |
| static_generator_context | static_generator, metadata | |
| static_generator_preread | static_generator | پیش از خوانده شدن یک فایل ایستا در StaticGenerator.generate_context فراخوانی میشود؛ اگر کد نیاز به انجام کاری پیش از اضافه شدن هر فایل ایستا به فهرست staticfiles دارد استفاده کنید. |
| static_generator_init | static_generator | در StaticGenerator.__init__ فراخوانی میشود |
| static_generator_finalized | static_generator | در انتهای StaticGenerator.generate_context فراخوانی میشود |
| content_object_init | content_object | در انتهای Content.__init__ فراخوانی میشود |
| content_written | path, context | هر بار که یک فایل محتوا نوشته میشود فراخوانی میشود. |
| feed_generated | context, feed | هر بار که یک فید تولید میشود فراخوانی میشود. میتواند برای تغییر شیء فید پیش از نوشته شدن آن استفاده شود. |
| feed_written | path, context, feed | هر بار که یک فایل فید نوشته میشود فراخوانی میشود. |
هشدار:
نکته:
| نام قدیمی | نام جدید |
| article_generate_context | article_generator_context |
| article_generate_finalized | article_generator_finalized |
| article_generate_preread | article_generator_preread |
| pages_generate_context | page_generator_context |
| pages_generate_preread | page_generator_preread |
| pages_generator_finalized | page_generator_finalized |
| pages_generator_init | page_generator_init |
| static_generate_context | static_generator_context |
| static_generate_preread | static_generator_preread |
در نهایت به این نتیجه رسیدیم که بهتر است برخی از دستورالعملهای ساخت افزونهها در جایی از مستندات به اشتراک گذاشته شوند، بنابراین این شما و این دستورالعملها!
نحوه ایجاد یک reader جدید
یکی از مواردی که ممکن است بخواهید، افزودن پشتیبانی از قالب ورودی اختصاصی خودتان است. در حالی که شاید افزودن این قابلیت به هسته Pelican منطقی به نظر برسد، ما هوشمندانه تصمیم گرفتیم از این وضعیت اجتناب کرده و در عوض readerهای مختلف را از طریق افزونهها تعریف کنیم.
دلیل اصلی این انتخاب آن است که نوشتن افزونهها واقعاً آسان است و هنگامی که فعال نیستند، سرعت خود Pelican را کاهش نمیدهند.
بدون توضیح بیشتر — در اینجا یک مثال آورده شده است:
from pelican import signals
from pelican.readers import BaseReader
# Create a new reader class, inheriting from the pelican.reader.BaseReader
class NewReader(BaseReader):
enabled = True # Yeah, you probably want that :-)
# The list of file extensions you want this reader to match with.
# If multiple readers were to use the same extension, the latest will
# win (so the one you're defining here, most probably).
file_extensions = ['yeah']
# You need to have a read method, which takes a filename and returns
# some content and the associated metadata.
def read(self, filename):
metadata = {'title': 'Oh yeah',
'category': 'Foo',
'date': '2012-12-01'}
parsed = {}
for key, value in metadata.items():
parsed[key] = self.process_metadata(key, value)
return "Some content", parsed
def add_reader(readers):
readers.reader_classes['yeah'] = NewReader
# This is how pelican works.
def register():
signals.readers_init.connect(add_reader)
افزودن یک generator جدید
افزودن یک generator جدید نیز بسیار آسان است. برای اطلاعات بیشتر درباره نحوه ایجاد generator اختصاصی خود، ممکن است بخواهید نگاهی به ساختار درونی Pelican (Pelican internals) <> بیندازید.
def get_generators(pelican_object):
# define a new generator here if you need to
return MyGenerator
def register():
signals.get_generators.connect(get_generators)
افزودن یک writer جدید
افزودن یک writer به شما این امکان را میدهد که قالبهای فایل بیشتری را در دیسک ذخیره کنید، یا نحوه نوشتن قالبهای موجود بر روی دیسک را تغییر دهید. توجه داشته باشید که در هر زمان تنها یک writer فعال خواهد بود، بنابراین مطمئن شوید که یا از کلاس Writer توکار (built-in) ارثبری میکنید، یا آن را کاملاً از نو پیادهسازی مینمایید.
در اینجا یک مثال پایهای از نحوه راهاندازی writer اختصاصی شما آورده شده است:
from pelican.writers import Writer
from pelican import signals
class MyWriter(Writer):
# define new writer functionality
pass
def add_writer(pelican_object):
# use pelican_instance to setup stuff if needed
return MyWriter
def register():
signals.get_writer.connect(add_writer)
استفاده از افزونهها برای تزریق محتوا
شما میتوانید با استفاده از افزونهها مقالهها یا صفحهها را به صورت برنامهنویسیشده تزریق کنید. این ویژگی برای نمونه در صورتی که بخواهید مقالهها را از یک API دریافت کنید، میتواند مفید باشد.
در ادامه یک مثال ساده از نحوه ساخت افزونهای آورده شده است که با استفاده از سیگنال article_generator_pretaxonomy یک مقاله سفارشی را تزریق میکند:
import datetime
from pelican import signals
from pelican.contents import Article
from pelican.readers import BaseReader
def addArticle(articleGenerator):
settings = articleGenerator.settings
# Author, category, and tags are objects, not strings, so they need to
# be handled using BaseReader's process_metadata() function.
baseReader = BaseReader(settings)
content = "I am the body of an injected article!"
newArticle = Article(content, {
"title": "Injected Article!",
"date": datetime.datetime.now(),
"category": baseReader.process_metadata("category", "fromAPI"),
"tags": baseReader.process_metadata("tags", "tagA, tagB")
})
articleGenerator.articles.insert(0, newArticle)
def register():
signals.article_generator_pretaxonomy.connect(addArticle)
مخزنی از پوستههای Pelican به نشانی https://github.com/getpelican/pelican-themes وجود دارد که توسط جامعهٔ کاربری برای اشتراکگذاری و استفادهٔ همگان مدیریت میشود.
لطفاً توجه داشته باشید اگرچه ما تمام تلاش خود را برای بررسی و ادغام مشارکتها در پوستهها به کار میگیریم، اما این پوستهها توسط جامعهٔ Pelican ارسال میشوند و در نتیجه ممکن است از سطوح متفاوتی از پشتیبانی و سازگاری برخوردار باشند.
ساخت پوستهها
برای تولید خروجی HTML، Pelican به دلیل انعطافپذیری و نحو سرراست موتور قالبساز Jinja https://palletsprojects.com/p/jinja از آن استفاده میکند. اگر مایلید پوستهٔ خودتان را بسازید، میتوانید از پوستهٔ "simple" در https://github.com/getpelican/pelican/tree/main/pelican/themes/simple/templates الهام بگیرید.
برای تولید سایت خود با استفاده از پوستهای که ساختهاید (یا به صورت دستی بارگیری کرده و سپس تغییر دادهاید)، میتوانید آن پوسته را از طریق پرچم -t مشخص کنید:
pelican content -s pelicanconf.py -t /projects/your-site/themes/your-theme
اگر ترجیح میدهید پوسته را در هر بار اجرای دستور مشخص نکنید، میتوانید متغیر THEME را در تنظیمات خود تعریف کنید تا به مکان پوستهٔ مورد نظر شما اشاره کند.
ساختار
برای ساخت پوستهٔ خود، باید ساختار زیر را رعایت کنید:
├── static
│ ├── css
│ └── images
└── templates
├── archives.html // to display archives
├── article.html // processed for each article
├── author.html // processed for each author
├── authors.html // must list all the authors
├── categories.html // must list all the categories
├── category.html // processed for each category
├── index.html // the index (list all the articles)
├── page.html // processed for each page
├── period_archives.html // to display time-period archives
├── tag.html // processed for each tag
└── tags.html // must list all the tags. Can be a tag cloud.
- پوشهٔ static شامل تمام داراییهای ایستا است که در پوشهٔ خروجی theme کپی خواهند شد. ساختار سامانهٔ فایل بالا شامل پوشههای CSS و تصاویر است، اما اینها فقط مثال هستند. هر آنچه نیاز دارید را اینجا قرار دهید.
- پوشهٔ templates شامل تمام قالبهایی است که برای تولید محتوا استفاده خواهند شد. فایلهای قالب فهرستشده در بالا اجباری هستند؛ اگر در هنگام ساخت پوسته، افزودن قالبهای اختصاصی به سازماندهی بهتر کمک میکند، میتوانید آنها را نیز اضافه کنید.
قالبها و متغیرها
ایدهٔ اصلی استفاده از نحو سادهای است که بتوانید آن را درون صفحات HTML خود بگنجانید. این سند توضیح میدهد چه قالبهایی باید در یک پوسته وجود داشته باشند، و چه متغیرهایی در زمان تولید به هر قالب ارسال خواهند شد.
تمام قالبها متغیرهای تعریفشده در فایل تنظیمات شما را دریافت خواهند کرد، مادامی که با حروف بزرگ (all-caps) باشند. میتوانید مستقیماً به آنها دسترسی داشته باشید.
متغیرهای عمومی
تمام این تنظیمات در دسترس همهٔ قالبها خواهند بود.
| متغیر | توضیحات |
| output_file | نام فایلی که در حال حاضر تولید میشود. به عنوان مثال، هنگامی که Pelican در حال پردازش صفحهٔ اصلی است، output_file برابر با "index.html" خواهد بود. |
| articles | فهرست مقالهها، مرتبشده به صورت نزولی بر اساس تاریخ. تمام عناصر اشیاء Article هستند، بنابراین میتوانید به ویژگیهای آنها (مانند title، summary، author و غیره) دسترسی پیدا کنید. گاهی این متغیر پوشانده (shadowed) میشود (برای مثال، در صفحهٔ برچسبها). در این صورت اطلاعات مربوط به آن را در متغیر all_articles خواهید یافت. |
| dates | همان فهرست مقالهها، اما مرتبشده بر اساس تاریخ به صورت صعودی. |
| hidden_articles | فهرست مقالههای پنهانشده |
| drafts | فهرست مقالههای پیشنویس |
| period_archives | یک دیکشنری شامل عناصر مربوط به بایگانیهای دورههای زمانی (در صورت فعال بودن). برای جزئیات بیشتر به بخش Listing and Linking to Period Archives مراجعه کنید. |
| authors | فهرستی از چندتاییهای (author, articles)، شامل تمام نویسندگان و مقالههای متناظر (مقادیر) |
| categories | فهرستی از چندتاییهای (category, articles)، شامل تمام دستهبندیها و مقالههای متناظر (مقادیر) |
| tags | فهرستی از چندتاییهای (tag, articles)، شامل تمام برچسبها و مقالههای متناظر (مقادیر) |
| pages | فهرست برگهها |
| hidden_pages | فهرست برگههای پنهانشده |
| draft_pages | فهرست برگههای پیشنویس |
| مرتبسازی (Sorting) | |
| پوششدهندههای URL (در حال حاضر دستهها، برچسبها، و نویسندگان)، دارای متدهای مقایسهای هستند که امکان مرتبسازی آسان آنها بر اساس نام را فراهم میکنند: | |
| 0.0 | |
| 3.5 | |
| {% for tag, articles in tags|sort %} | |
| 168u | |
| 168u | |
| اگر میخواهید بر اساس معیارهای متفاوتی مرتبسازی را انجام دهید، دستور sort در Jinja به نشانی https://jinja.palletsprojects.com/en/latest/templates/#sort گزینههای متعددی دارد. | |
| قالببندی تاریخ (Date Formatting) | |
| Pelican تاریخ را مطابق با تنظیمات و محلیسازی (locale) شما (DATE_FORMATS/DEFAULT_DATE_FORMAT) قالببندی کرده و یک صفت locale_date فراهم میکند. از طرف دیگر، صفت date یک شیء datetime https://docs.python.org/3/library/datetime.html#datetime-objects خواهد بود. اگر برای یک تاریخ به قالببندی سفارشی متفاوتی با تنظیمات خود نیاز دارید، از پالایهٔ strftime در Jinja که همراه با Pelican ارائه میشود استفاده کنید. نحوهٔ استفاده مانند قالب strftime در Python https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior است، اما این پالایه کار درست را انجام داده و تاریخ شما را مطابق با محلیسازی مشخصشده در تنظیمات قالببندی خواهد کرد: | |
| 0.0 | |
| 3.5 | |
| {{ article.date|strftime('%d %B %Y') }} | |
| 168u | |
| 168u | |
| بررسی افزونههای بارگذاریشده (Checking Loaded Plugins) | |
| Pelican یک تست Jinja به نام plugin_enabled برای بررسی فعال بودن یک افزونه مشخص فراهم میکند. این تست نام افزونه را به صورت رشته دریافت کرده و یک مقدار بولی (Boolean) بازمیگرداند. افزونههای فضای نام را میتوان با نام کامل (pelican.plugins.plugin_name) یا نام کوتاه (plugin_name) مشخص کرد. مثال زیر در صورت فعال بودن افزونهٔ webassets از آن برای فشردهسازی (minify) فایل CSS استفاده میکند و در غیر این صورت به CSS معمولی بازمیگردد: | |
| 0.0 | |
| 3.5 | |
| {% if "webassets" is plugin_enabled %} | |
| {% assets filters="cssmin", output="css/style.min.css", "css/style.scss" %} | |
| <link rel="stylesheet" href="{{SITEURL}}/{{ASSET_URL}}"> | |
| {% endassets %} | |
| {% else %} | |
| <link rel="stylesheet" href="{{SITEURL}}/css/style.css}"> | |
| {% endif %} | |
| 168u | |
| 168u | |
| index.html | |
| این صفحهٔ اصلی یا نمایهٔ وبلاگ شما است که در index.html تولید میشود. | |
| اگر صفحهبندی فعال باشد، صفحههای بعدی در index{number}.html قرار خواهند گرفت. | |
| box center; | |
| l|l. | |
| متغیر | توضیحات |
| articles_paginator | یک شیء paginator برای فهرست مقالهها |
| articles_page | صفحهٔ جاری مقالهها |
| articles_previous_page | صفحهٔ قبلی مقالهها (در صورت عدم وجود صفحه، None) |
| articles_next_page | صفحهٔ بعدی مقالهها (در صورت عدم وجود صفحه، None) |
| dates_paginator | یک شیء paginator برای فهرست مقالهها، مرتبشده بر اساس تاریخ، صعودی. |
| dates_page | صفحهٔ جاری مقالهها، مرتبشده بر اساس تاریخ، صعودی. |
| dates_previous_page | صفحهٔ قبلی مقالهها، مرتبشده بر اساس تاریخ، صعودی (در صورت عدم وجود صفحه، None) |
| dates_next_page | صفحهٔ بعدی مقالهها، مرتبشده بر اساس تاریخ، صعودی (در صورت عدم وجود صفحه، None) |
| page_name | 'index' -- مفید برای پیوندهای صفحهبندی |
| این قالب برای هر یک از نویسندگان موجود پردازش میشود و خروجی بر اساس تنظیم | |
| AUTHOR_SAVE_AS (پیشفرض: author/{slug}.html) تولید میگردد. اگر | |
| صفحهبندی فعال باشد، صفحات بعدی بهطور پیشفرض در | |
| author/{slug}{number}.html قرار خواهند گرفت. | |
| box center; | |
| l|l. | |
| متغیر | توضیحات |
| author | نام نویسندهای که در حال پردازش است |
| articles | مقالههای این نویسنده |
| dates | مقالههای این نویسنده، اما مرتبشده بر اساس تاریخ، صعودی |
| articles_paginator | یک شیء صفحهبند برای فهرست مقالهها |
| articles_page | صفحه کنونی مقالهها |
| articles_previous_page | صفحه قبلی مقالهها (اگر صفحه وجود نداشته باشد، None) |
| articles_next_page | صفحه بعدی مقالهها (اگر صفحه وجود نداشته باشد، None) |
| dates_paginator | یک شیء صفحهبند برای فهرست مقالهها، مرتبشده بر اساس تاریخ، صعودی. |
| dates_page | صفحه کنونی مقالهها، مرتبشده بر اساس تاریخ، صعودی. |
| dates_previous_page | صفحه قبلی مقالهها، مرتبشده بر اساس تاریخ، صعودی (اگر صفحه وجود نداشته باشد، None) |
| dates_next_page | صفحه بعدی مقالهها، مرتبشده بر اساس تاریخ، صعودی (اگر صفحه وجود نداشته باشد، None) |
| page_name | مقدار AUTHOR_URL که در آن هر چیزی پس از {slug} حذف شده است -- مفید برای پیوندهای صفحهبندی |
category.html
این قالب برای هر یک از دستههای موجود پردازش میشود و خروجی بر اساس تنظیم CATEGORY_SAVE_AS (پیشفرض: category/{slug}.html) تولید میگردد. اگر صفحهبندی فعال باشد، صفحات بعدی بهطور پیشفرض در category/{slug}{number}.html قرار خواهند گرفت.
| متغیر | توضیحات |
| category | نام دستهای که در حال پردازش است |
| articles | مقالههای این دسته |
| dates | مقالههای این دسته، اما مرتبشده بر اساس تاریخ، صعودی |
| articles_paginator | یک شیء صفحهبند برای فهرست مقالهها |
| articles_page | صفحه کنونی مقالهها |
| articles_previous_page | صفحه قبلی مقالهها (اگر صفحه وجود نداشته باشد، None) |
| articles_next_page | صفحه بعدی مقالهها (اگر صفحه وجود نداشته باشد، None) |
| dates_paginator | یک شیء صفحهبند برای فهرست مقالهها، مرتبشده بر اساس تاریخ، صعودی |
| dates_page | صفحه کنونی مقالهها، مرتبشده بر اساس تاریخ، صعودی |
| dates_previous_page | صفحه قبلی مقالهها، مرتبشده بر اساس تاریخ، صعودی (اگر صفحه وجود نداشته باشد، None) |
| dates_next_page | صفحه بعدی مقالهها، مرتبشده بر اساس تاریخ، صعودی (اگر صفحه وجود نداشته باشد، None) |
| page_name | مقدار CATEGORY_URL که در آن هر چیزی پس از {slug} حذف شده است -- مفید برای پیوندهای صفحهبندی |
| این قالب برای هر مقاله پردازش خواهد شد و خروجی بر اساس تنظیم ARTICLE_SAVE_AS (پیشفرض: {slug}.html) تولید میشود. هنگام رندر، متغیرهای زیر در دسترس هستند. | |
| box center; | |
| l|l. | |
| متغیر | توضیحات |
| article | شیء مقالهای که باید نمایش داده شود |
| category | نام دستهبندی برای مقالهٔ فعلی |
هر فرادادهای که در سرآیند فایل منبع مقاله قرار دهید، به عنوان فیلدهایی در شیء article در دسترس خواهد بود. نام فیلد با نام فیلد فراداده یکسان خواهد بود، با این تفاوت که تمام نویسهها به حروف کوچک تبدیل میشوند.
برای مثال، میتوانید فیلدی به نام FacebookImage را همانند نمونهٔ زیر به فرادادههای مقالهٔ خود اضافه کنید:
Title: I love Python more than music Date: 2013-11-06 10:06 Tags: personal, python Category: Tech Slug: python-je-l-aime-a-mourir Author: Francis Cabrel FacebookImage: http://franciscabrel.com/images/pythonlove.png
این فرادادهٔ جدید به صورت article.facebookimage در قالب article.html شما در دسترس خواهد بود. برای مثال، این ویژگی به شما امکان میدهد تصویری را برای برچسبهای open graph فیسبوک مشخص کنید که برای هر مقاله تغییر کند:
<meta property="og:image" content="{{ article.facebookimage }}"/>
page.html
این قالب برای هر برگه پردازش خواهد شد و خروجی بر اساس تنظیم PAGE_SAVE_AS (پیشفرض: pages/{slug}.html) تولید میشود. هنگام رندر، متغیرهای زیر در دسترس هستند.
| متغیر | توضیحات |
| page | شیء برگهای که باید نمایش داده شود. میتوانید به title، slug و content آن دسترسی داشته باشید. |
tag.html
این قالب برای هر برچسب پردازش خواهد شد و خروجی بر اساس تنظیم TAG_SAVE_AS (پیشفرض: tag/{slug}.html) تولید میشود. اگر صفحهبندی فعال باشد، صفحههای بعدی بهطور پیشفرض در tag/{slug}{number}.html قرار میگیرند.
| متغیر | توضیحات |
| tag | نام برچسبی که در حال پردازش است |
| articles | مقالههای مربوط به این برچسب |
| dates | مقالههای مربوط به این برچسب، ولی مرتبشده بر اساس تاریخ، صعودی |
| articles_paginator | یک شیء صفحهبندیکننده (paginator) برای فهرست مقالهها |
| articles_page | صفحهٔ فعلی مقالهها |
| articles_previous_page | صفحهٔ قبلی مقالهها (اگر صفحه وجود نداشته باشد، None) |
| articles_next_page | صفحهٔ بعدی مقالهها (اگر صفحه وجود نداشته باشد، None) |
| dates_paginator | یک شیء صفحهبندیکننده برای فهرست مقالهها، مرتبشده بر اساس تاریخ، صعودی |
| dates_page | صفحهٔ فعلی مقالهها، مرتبشده بر اساس تاریخ، صعودی |
| dates_previous_page | صفحهٔ قبلی مقالهها، مرتبشده بر اساس تاریخ، صعودی (اگر صفحه وجود نداشته باشد، None) |
| dates_next_page | صفحهٔ بعدی مقالهها، مرتبشده بر اساس تاریخ، صعودی (اگر صفحه وجود نداشته باشد، None) |
| page_name | مقدار TAG_URL که همه چیز بعد از {slug} در آن حذف شده است -- برای پیوندهای صفحهبندی مفید است |
| اگر مسیری برای YEAR_ARCHIVE_SAVE_AS تعریف شده باشد، این قالب برای هر سال از پستهای شما پردازش خواهد شد؛ اگر MONTH_ARCHIVE_SAVE_AS تعریف شده باشد برای هر ماه، و اگر DAY_ARCHIVE_SAVE_AS تعریف شده باشد برای هر روز پردازش میشود. | |
| box center; | |
| l|l. | |
| متغیر | توضیحات |
| period | تاپلی به صورت (year, month, day) که دوره زمانی جاری را مشخص میکند. year و day عدد هستند در حالی که month یک رشته است. این تاپل تنها در صورتی شامل year است که دوره زمانی مربوط به یک سال مشخص باشد. اگر دوره زمانی سال و ماه را در بر بگیرد شامل هر دو year و month خواهد بود و به همین ترتیب. |
| period_num | تاپلی به صورت (year, month, day)، مشابه period، با این تفاوت که تمام مقادیر عدد هستند. |
میتوانید نمونهای از نحوه استفاده از period را در قالب period_archives.html از پوسته "simple" مشاهده کنید: https://github.com/getpelican/pelican/blob/main/pelican/themes/simple/templates/period_archives.html.
فهرستبندی و پیوند به آرشیوهای دورهای (Listing and Linking to Period Archives)
متغیر period_archives میتواند برای ایجاد فهرستی از پیوندها به مجموعهای از آرشیوهای دورهای که Pelican تولید میکند، استفاده شود. به عنوان یک متغیر عمومی، در هر قالبی قابل استفاده است؛ بنابراین میتوانید چنین نمایهای را در یک قالب مستقیم سفارشی یا در یک نوار کناری که در صفحات مختلف سایت قابل مشاهده است، پیادهسازی کنید.
period_archives یک دیکشنری (dict) است که بسته به فعال بودن هر یک از تنظیمات *_ARCHIVE_SAVE_AS، ممکن است شامل کلیدهای year، month و/یا day باشد. مقدار متناظر، فهرستی از دیکشنریها است که هر دیکشنری به نوبه خود نمایانگر یک دوره زمانی (مرتبشده بر اساس تنظیمات NEWEST_FIRST_ARCHIVES) با کلیدها و مقادیر زیر است:
| کلید | مقدار |
| period | همان تاپلی که در period_archives.html شرح داده شده است، مانند (2023, 'June', 18). |
| period_num | همان تاپلی که در period_archives.html شرح داده شده است، مانند (2023, 6, 18). |
| url | نشانی وب (URL) مربوط به صفحه آرشیو دورهای، مانند posts/2023/06/18/. این مقدار توسط تنظیمات متناظر *_ARCHIVE_URL کنترل میشود. |
| save_as | مسیر محل ذخیرهسازی فایل صفحه آرشیو دورهای، مانند posts/2023/06/18/index.html. این مقدار به صورت داخلی توسط Pelican استفاده میشود و معمولاً ارتباطی با پوستهها ندارد. |
| articles | فهرستی از اشیاء Article که در این دوره زمانی قرار میگیرند. |
| dates | همان فهرست articles، اما مرتبشده بر اساس تنظیمات NEWEST_FIRST_ARCHIVES. |
در اینجا نمونهای از نحوه استفاده از period_archives در یک قالب آورده شده است:
<ul>
{% for archive in period_archives.month %}
<li>
<a href="{{ SITEURL }}/{{ archive.url }}">
{{ archive.period | reverse | join(' ') }} ({{ archive.articles|count }})
</a>
</li>
{% endfor %}
</ul>
میتوانید بر اساس سطح جزئیات دوره زمانی مورد نظر، period_archives.month را در عبارت for به دلخواه به period_archives.year یا period_archives.day تغییر دهید..SS اشیاء (Objects)
جزئیات ویژگیهای اشیایی که در قالبها در دسترس و کاربردی هستند را شرح میدهد. همهٔ ویژگیها در اینجا فهرست نشدهاند؛ این بخش مجموعهای گزینششده از ویژگیهایی است که برای استفاده در قالب مفید ارزیابی شدهاند.
مقاله (Article)
نمایش رشتهای یک Article، ویژگی source_path است.
| ویژگی | توضیحات |
| author | نویسندهٔ این مقاله. |
| authors | فهرستی از نویسندگان این مقاله. |
| category | دستهبندی این مقاله. |
| content | محتوای رندرشدهٔ مقاله. |
| date | شیء Datetime نمایانگر تاریخ مقاله. |
| date_format | قالب پیشفرض تاریخ یا قالب تاریخ محلی (locale). |
| default_template | نام قالب پیشفرض. |
| in_default_lang | مقدار بولی که نشان میدهد آیا مقاله به زبان پیشفرض نوشته شده است یا خیر. |
| lang | زبان مقاله. |
| locale_date | تاریخ قالببندیشده توسط date_format. |
| metadata | دیکشنری (dict) فرادادههای سرآیند مقاله. |
| save_as | محل ذخیرهٔ صفحهٔ مقاله. |
| slug | اسلاگ (slug) صفحه. |
| source_path | مسیر کامل سیستمی فایل منبع مقاله. |
| relative_source_path | مسیر نسبی از PATH <settings.html#PATH> تا فایل منبع مقاله. |
| status | وضعیت مقاله، میتواند یکی از مقادیر 'published' یا 'draft' باشد. |
| summary | محتوای چکیدهٔ رندرشده. |
| tags | فهرستی از اشیاء Tag. |
| template | نام قالب مورد استفاده برای رندر کردن. |
| title | عنوان مقاله. |
| translations | فهرستی از اشیاء Article ترجمهها. |
| url | نشانی URL به صفحهٔ مقاله. |
| نمایش رشتهای این اشیاء، صفت name است. | |
| box center; | |
| l|l. | |
| صفت | توضیحات |
| name | نام این شیء [1]. |
| page_name | نام صفحهٔ نویسنده. |
| save_as | مکان ذخیرهسازی صفحهٔ نویسنده. |
| slug | نامک (Slug) صفحه. |
| url | نشانی اینترنتی (URL) صفحهٔ نویسنده. |
- [1]
- برای شیء Author، برگرفته از :authors: یا AUTHOR.
صفحه (Page)
نمایش رشتهای یک صفحه (Page)، صفت source_path است.
| صفت | توضیحات |
| author | نویسندهٔ (Author) این صفحه. |
| content | محتوای رندرشدهٔ صفحه. |
| date | شیء Datetime که تاریخ صفحه را نشان میدهد. |
| date_format | قالب تاریخ پیشفرض یا قالب تاریخ محلی (locale). |
| default_template | نام قالب پیشفرض. |
| in_default_lang | مقدار بولی (Boolean) که مشخص میکند آیا مقاله به زبان پیشفرض نوشته شده است یا خیر. |
| lang | زبان مقاله. |
| locale_date | تاریخ قالببندیشده توسط date_format. |
| metadata | دیکشنری (dict) متادادههای سرآیند صفحه. |
| save_as | مکان ذخیرهسازی صفحه. |
| slug | نامک (Slug) صفحه. |
| source_path | مسیر کامل سیستمی فایل منبع صفحه. |
| relative_source_path | مسیر نسبی از PATH <settings.html#PATH> به فایل منبع صفحه. |
| status | وضعیت صفحه؛ میتواند یکی از مقادیر 'published'، 'hidden' یا 'draft' باشد. |
| summary | محتوای چکیدهٔ رندرشده. |
| tags | فهرستی از اشیاء Tag. |
| template | نام قالب مورد استفاده برای رندر کردن. |
| title | عنوان صفحه. |
| translations | فهرستی از ترجمهها (اشیاء Article). |
| url | نشانی اینترنتی (URL) صفحه. |
| متغیرهای فید در نسخهٔ ۳.۰ تغییر کردهاند. اکنون در نام هر متغیر بهطور صریح ATOM یا RSS ذکر شده است. مقدار پیشفرض همچنان ATOM است. پوستههای قدیمی باید بهروزرسانی شوند. در ادامه فهرست کاملی از متغیرهای فید آمده است: | |
| 0.0 | |
| 3.5 | |
| AUTHOR_FEED_ATOM | |
| AUTHOR_FEED_RSS | |
| CATEGORY_FEED_ATOM | |
| CATEGORY_FEED_RSS | |
| FEED_ALL_ATOM | |
| FEED_ALL_RSS | |
| FEED_ATOM | |
| FEED_RSS | |
| TAG_FEED_ATOM | |
| TAG_FEED_RSS | |
| TRANSLATION_FEED_ATOM | |
| TRANSLATION_FEED_RSS | |
| 168u | |
| 168u | |
| توارث (Inheritance) | |
| از نسخهٔ ۳.۰، Pelican از توارث از پوستهٔ simple پشتیبانی میکند؛ بنابراین میتوانید از قالبهای پوستهٔ simple در پوستههای خود مجدداً استفاده کنید. | |
| اگر یکی از فایلهای اجباری در دایرکتوری templates/ پوستهٔ شما وجود نداشته باشد، قالب متناظر آن از پوستهٔ simple جایگزین آن خواهد شد. بنابراین اگر ساختار HTML یک قالب در پوستهٔ simple برای شما مناسب است، نیازی نیست یک قالب جدید را از ابتدا بنویسید. | |
| همچنین میتوانید با استفاده از دستور {% extends %} مانند مثال زیر، قالبهای پوستهٔ simple را در پوستههای خود گسترش دهید: | |
| 0.0 | |
| 3.5 | |
| {% extends "!simple/index.html" %} <!-- extends the ``index.html`` template from the ``simple`` theme --> | |
| {% extends "index.html" %} <!-- "regular" extending --> | |
| 168u | |
| 168u | |
| مثال (Example) | |
| با این ساختار، امکان ایجاد یک پوسته تنها با دو فایل وجود دارد. | |
| base.html | |
| فایل نخست، قالب templates/base.html است: | |
| 0.0 | |
| 3.5 | |
| {% extends "!simple/base.html" %} | |
| {% block head %} | |
| {{ super() }} | |
| <link rel="stylesheet" type="text/css" href="{{ SITEURL }}/theme/css/style.css" /> | |
| {% endblock %} | |
| 168u | |
| 168u | |
| 0.0 | |
| 1. 3 | |
| در خط اول، قالب base.html را از پوستهٔ simple گسترش میدهیم، بنابراین نیازی به بازنویسی کل فایل نداریم. | |
| 2. 3 | |
| در خط سوم، بلوک head را که پیشتر در پوستهٔ simple تعریف شده است باز میکنیم. | |
| 3. 3 | |
| در خط چهارم، تابع super() محتوایی را که قبلاً در بلوک head درج شده بود حفظ میکند. | |
| 4. 3 | |
| در خط پنجم، یک شیوهنامه را به صفحه اضافه میکنیم. | |
| 5. 3 | |
| در خط آخر، بلوک head را میبندیم. | |
| 168u | |
| این فایل توسط تمام قالبهای دیگر گسترش خواهد یافت، بنابراین این شیوهنامه در تمام صفحات پیوند داده میشود. | |
| style.css | |
| فایل دوم، شیوهنامهٔ CSS در مسیر static/css/style.css است: | |
| 0.0 | |
| 3.5 | |
| body { | |
| font-family : monospace ; | |
| font-size : 100% ; | |
| background-color : white ; | |
| color : #111 ; | |
| width : 80% ; | |
| min-width : 400px ; | |
| min-height : 200px ; | |
| padding : 1em ; | |
| margin : 5% 10% ; | |
| border : thin solid gray ; | |
| border-radius : 5px ; | |
| display : block ; | |
| } | |
| a:link { color : blue ; text-decoration : none ; } | |
| a:hover { color : blue ; text-decoration : underline ; } | |
| a:visited { color : blue ; } | |
| h1 a { color : inherit !important } | |
| h2 a { color : inherit !important } | |
| h3 a { color : inherit !important } | |
| h4 a { color : inherit !important } | |
| h5 a { color : inherit !important } | |
| h6 a { color : inherit !important } | |
| pre { | |
| margin : 2em 1em 2em 4em ; | |
| } | |
| #menu li { | |
| display : inline ; | |
| } | |
| #post-list { | |
| margin-bottom : 1em ; | |
| margin-top : 1em ; | |
| } | |
| 168u | |
| میتوانید این تم نمونه را از اینجا بارگیری کنید. | |
| pelican-themes | |
| توضیحات (Description) | |
| pelican-themes یک ابزار خط فرمانی برای مدیریت تمها برای Pelican است. برای تنظیمات مربوط به تمها، بخش Themes <#settings-themes> را ببینید. | |
| کاربرد (Usage) |
| pelican-themes [-h] [-l] [-i theme path [theme path ...]] |
| +2 |
| [-r theme name [theme name ...]] |
| [-s theme path [theme path ...]] [-v] [--version] |
| -2 |
| آرگومانهای اختیاری (Optional arguments): | |
| 0.0 | |
| -h, --help | |
| نمایش راهنما و خروج | |
| -l, --list | |
| نمایش تمهای از قبل نصبشده | |
| -i theme_path, --install theme_path | |
| یک یا چند تم برای نصب | |
| -r theme_name, --remove theme_name | |
| یک یا چند تم برای حذف | |
| -s theme_path, --symlink theme_path | |
| مشابه --install، اما به جای رونوشت گرفتن از تم، یک پیوند نمادین ایجاد میکند. برای توسعه تم مفید است | |
| -v, --verbose | |
| خروجی با جزئیات کامل | |
| --version | |
| چاپ نسخه این اسکریپت | |
| 168u | |
| مثالها (Examples) | |
| فهرست کردن تمهای نصبشده (Listing the installed themes) | |
| با pelican-themes، میتوانید با استفاده از گزینه -l یا --list تمهای موجود را ببینید: | |
| 0.0 | |
| 3.5 | |
| $ pelican-themes -l | |
| notmyidea | |
| two-column@ | |
| simple | |
| $ pelican-themes --list | |
| notmyidea | |
| two-column@ | |
| simple | |
| 168u | |
| 168u | |
| در این مثال، مشاهده میکنیم که سه تم در دسترس است: notmyidea، simple و two-column. | |
| پس از two-column یک نماد @ آمده است، زیرا این تم در مسیر تمهای Pelican رونوشت نشده، بلکه فقط به آن پیوند داده شده است (برای جزئیات درباره ایجاد پیوندهای نمادین، Creating symbolic links را ببینید). | |
| توجه داشته باشید که میتوانید گزینه --list را با گزینه -v یا --verbose ترکیب کنید تا خروجی دقیقتری دریافت کنید، مانند این: | |
| 0.0 | |
| 3.5 | |
| $ pelican-themes -v -l | |
| /usr/local/lib/python2.6/dist-packages/pelican-2.6.0-py2.6.egg/pelican/themes/notmyidea | |
| /usr/local/lib/python2.6/dist-packages/pelican-2.6.0-py2.6.egg/pelican/themes/two-column (symbolic link to `/home/skami/Dev/Python/pelican-themes/two-column') | |
| /usr/local/lib/python2.6/dist-packages/pelican-2.6.0-py2.6.egg/pelican/themes/simple | |
| 168u | |
| 168u | |
| نصب تمها (Installing themes) | |
| میتوانید با استفاده از گزینه -i یا --install یک یا چند تم را نصب کنید. این گزینه مسیر(های) تم(هایی) را که میخواهید نصب کنید به عنوان آرگومان میپذیرد و میتواند با گزینه --verbose ترکیب شود: | |
| 0.0 | |
| 3.5 | |
| # pelican-themes --install ~/Dev/Python/pelican-themes/notmyidea-cms --verbose | |
| 168u | |
| 168u | |
| 0.0 | |
| 3.5 | |
| # pelican-themes --install ~/Dev/Python/pelican-themes/notmyidea-cms\ | |
| ~/Dev/Python/pelican-themes/martyalchin \ | |
| --verbose | |
| 168u | |
| 168u | |
| 0.0 | |
| 3.5 | |
| # pelican-themes -vi ~/Dev/Python/pelican-themes/two-column | |
| 168u | |
| 168u | |
| حذف تمها (Removing themes) | |
| دستور pelican-themes همچنین میتواند تمها را از مسیر تمهای Pelican حذف کند. گزینه -r یا --remove نام(های) تم(هایی) را که میخواهید حذف کنید به عنوان آرگومان میگیرد و میتواند با گزینه --verbose ترکیب شود. | |
| 0.0 | |
| 3.5 | |
| # pelican-themes --remove two-column | |
| 168u | |
| 168u | |
| 0.0 | |
| 3.5 | |
| # pelican-themes -r martyachin notmyidea-cmd -v | |
| 168u | |
| دستور pelican-themes میتواند به جای کپی کردن کل قالبها در مسیر قالبهای Pelican، آنها را با ایجاد پیوندهای نمادین (symbolic links) نیز نصب کند. | |
| برای ایجاد پیوند نمادین یک قالب، میتوانید از گزینهٔ -s یا --symlink استفاده کنید که دقیقاً مانند گزینهٔ --install کار میکند: | |
| 0.0 | |
| 3.5 | |
| # pelican-themes --symlink ~/Dev/Python/pelican-themes/two-column | |
| 168u | |
| 168u | |
| در این مثال، اکنون قالب two-column به صورت نمادین به مسیر قالبهای Pelican پیوند داده شده است؛ بنابراین میتوانیم از آن استفاده کنیم، و در عین حال میتوانیم بدون نیاز به نصب مجدد پس از هر ویرایش، آن را تغییر دهیم. | |
| این قابلیت برای توسعهٔ قالب بسیار کاربردی است: | |
| 0.0 | |
| 3.5 | |
| $ sudo pelican-themes -s ~/Dev/Python/pelican-themes/two-column | |
| $ pelican ~/Blog/content -o /tmp/out -t two-column | |
| $ firefox /tmp/out/index.html | |
| $ vim ~/Dev/Pelican/pelican-themes/two-column/static/css/main.css | |
| $ pelican ~/Blog/content -o /tmp/out -t two-column | |
| $ cp /tmp/bg.png ~/Dev/Pelican/pelican-themes/two-column/static/img/bg.png | |
| $ pelican ~/Blog/content -o /tmp/out -t two-column | |
| $ vim ~/Dev/Pelican/pelican-themes/two-column/templates/index.html | |
| $ pelican ~/Blog/content -o /tmp/out -t two-column | |
| 168u | |
| 168u | |
| انجام همزمان چندین عملیات | |
| گزینههای --install، --remove و --symlink با یکدیگر مانعةالجمع نیستند؛ بنابراین میتوانید آنها را در یک خط فرمان با هم ترکیب کنید تا همزمان بیش از یک عملیات انجام شود، مانند این: | |
| 0.0 | |
| 3.5 | |
| # pelican-themes --remove notmyidea-cms two-column \ | |
| --install ~/Dev/Python/pelican-themes/notmyidea-cms-fr \ | |
| --symlink ~/Dev/Python/pelican-themes/two-column \ | |
| --verbose | |
| 168u | |
| 168u | |
| در این مثال، قالب notmyidea-cms با قالب notmyidea-cms-fr جایگزین میشود. | |
| وارد کردن یک وبگاه موجود | |
| توضیحات | |
| دستور pelican-import یک ابزار خط فرمانی برای تبدیل مقالهها از نرمافزارهای دیگر به reStructuredText یا Markdown است. قالبهای پشتیبانیشده برای واردسازی عبارتند از: | |
| 0.0 | |
| • 2 | |
| خروجی XML از Blogger | |
| • 2 | |
| خروجی Dotclear | |
| • 2 | |
| خروجی Medium | |
| • 2 | |
| رابط برنامهنویسی Tumblr API | |
| • 2 | |
| خروجی XML از WordPress | |
| • 2 | |
| خوراک RSS/Atom | |
| 168u | |
| تبدیل از HTML به reStructuredText یا Markdown به Pandoc https://pandoc.org متکی است. | |
| در Dotclear، اگر پستهای مبدأ با ساختار Markdown نوشته شده باشند، تبدیل نخواهند شد (زیرا Pelican خود از Markdown پشتیبانی میکند). | |
| نکته: | |
| 0.0 | |
| 3.5 | |
| برخلاف Pelican، سیستم مدیریت محتوای Wordpress از چندین دستهبندی برای هر مقاله پشتیبانی میکند. این دستهبندیها به عنوان یک رشتهٔ جداشده با کاما وارد میشوند. باید این موارد را به صورت دستی تفکیک کنید، یا از افزونهای مانند More Categories https://github.com/pelican-plugins/more-categories استفاده کنید که دستهبندیهای چندگانه را برای هر مقاله فعال میسازد. | |
| 168u | |
| 168u | |
| نکته: | |
| 0.0 | |
| 3.5 | |
| صفحات واردشده ممکن است حاوی پیوندهایی به تصاویری باشند که همچنان به وبگاه اصلی اشاره دارند. بنابراین شاید بخواهید آن تصاویر را در محتوای محلی خود بارگیری کرده و پیوند آنها را در صفحات مربوطه از وبگاه خود به صورت دستی بازسازی کنید. | |
| 168u | |
| 168u | |
| وابستگیها | |
| دستور pelican-import وابستگیهایی دارد که برای سایر بخشهای Pelican الزامی نیستند: | |
| 0.0 | |
| • 2 | |
| بستههای BeautifulSoup4 و lxml، برای وارد کردن از WordPress و Dotclear. میتوان آنها را مانند سایر بستههای پایتون نصب کرد (pip install BeautifulSoup4 lxml). | |
| • 2 | |
| بستهٔ Feedparser، برای وارد کردن خوراک (pip install feedparser). | |
| • 2 | |
| ابزار Pandoc، برای راهنمای نصب روی سیستمعامل خود به وبگاه Pandoc https://pandoc.org/installing.html مراجعه کنید. | |
| 168u | |
| نحوه استفاده | |
| 0.0 | |
| 3.5 | |
| pelican-import [-h] [--blogger] [--dotclear] [--tumblr] [--wpfile] [--feed] | |
| [-o OUTPUT] [-m MARKUP] [--dir-cat] [--dir-page] [--strip-raw] [--wp-custpost] | |
| [--wp-attach] [--disable-slugs] [-b BLOGNAME] | |
| input|api_key | |
| 168u | |
| 0.0 | |
| 3.5 | |
| box center; | |
| l|l. | |
| input | فایل ورودی برای خواندن |
| api_key | (فقط در Tumblr) کلید api_key را میتوان از https://www.tumblr.com/oauth/apps دریافت کرد |
گزینههای اختیاری (Optional arguments)
- -h, --help
- نمایش این پیام راهنما و خروج
- --blogger
- برونبری XML از Blogger (پیشفرض: False)
- --dotclear
- برونبری Dotclear (پیشفرض: False)
- --medium
- برونبری Medium (پیشفرض: False)
- --tumblr
- رابط برنامهنویسی Tumblr API (پیشفرض: False)
- --wpfile
- برونبری XML از WordPress (پیشفرض: False)
- --feed
- خوراک (feed) برای تجزیه (پیشفرض: False)
- -o OUTPUT, --output OUTPUT
- مسیر خروجی (پیشفرض: content)
- -m MARKUP, --markup MARKUP
- قالب نشانهگذاری خروجی: rst، markdown یا asciidoc (پیشفرض: rst)
- --dir-cat
- قرار دادن فایلها در دایرکتوریهایی با نام دستهبندیها (پیشفرض: False)
- --dir-page
- قرار دادن فایلهای شناختهشده بهعنوان برگه در زیردایرکتوری "pages/" (فقط در درونریزی blogger و wordpress) (پیشفرض: False)
- --filter-author
- درونریزی فقط پستهای متعلق به نویسندهٔ مشخصشده
- --strip-raw
- حذف کدهای خام HTML که امکان تبدیل آنها به نشانهگذاری وجود ندارد، مانند فلشهای جاسازیشده یا iframeها (پیشفرض: False)
- --wp-custpost
- قرار دادن انواع پست سفارشی وردپرس در دایرکتوریها. اگر همراه با گزینهٔ --dir-cat استفاده شود، دایرکتوریها بهصورت "/post_type/category/" ایجاد خواهند شد (فقط در درونریزی wordpress)
- --wp-attach
- دانلود فایلهای بارگذاریشده در وردپرس بهعنوان پیوست. فایلها بهصورت یک فهرست در سرآیند پست اضافه شده و پیوندهای درون پست به فایلها بهروزرسانی خواهند شد. تمام فایلها دانلود خواهند شد، حتی اگر به پستی وابسته نباشند. فایلها با مسیر اصلیشان درون دایرکتوری خروجی دانلود میشوند، مانند "output/wp-uploads/date/postname/file.jpg". (فقط در درونریزی wordpress) (نیازمند اتصال اینترنت)
- --disable-slugs
- غیرفعال کردن ذخیرهٔ نامکها (slugs) از پستهای درونریزیشده در خروجی. با غیرفعال بودن این گزینه، ممکن است نشانیهای اینترنتی Pelican با پستهای اصلی شما سازگار نباشند. (پیشفرض: False)
- -b BLOGNAME, --blogname=BLOGNAME
- نام وبلاگ مورد استفاده در Tumblr API
مثالها (Examples)
برای Blogger:
$ pelican-import --blogger -o ~/output ~/posts.xml
برای Dotclear:
$ pelican-import --dotclear -o ~/output ~/backup.txt
برای Medium:
$ pelican-import --medium -o ~/output ~/medium-export/posts/
برونبری Medium یک فایل zip است. آن را از حالت فشرده خارج کرده و این ابزار را به زیردایرکتوری "posts" هدایت کنید. برای کسب اطلاعات بیشتر دربارهٔ نحوهٔ برونبری، ببینید: https://help.medium.com/hc/en-us/articles/115004745787-Export-your-account-data.
برای Tumblr:
$ pelican-import --tumblr -o ~/output --blogname=<blogname> <api_key>
برای WordPress:
$ pelican-import --wpfile -o ~/output ~/posts.xml
برای Medium (یک مثال از استفاده از خوراک RSS):
نکته:
برای آزمودن این ماژول، میتوان از فایلهای نمونه استفاده کرد:
پرسشهای متداول (FAQ)
در اینجا برخی از پرسشهای متداول پیرامون Pelican آورده شده است.
بهترین راه برای مطرح کردن یک مشکل، پرسش یا پیشنهاد چیست؟
لطفاً شیوهنامههای بازخورد ما را در <> مطالعه کنید.
چگونه میتوانم کمک کنم؟
راههای متعددی برای کمک کردن وجود دارد. نخست، میتوانید هرگونه پیشنهاد یا مشکل مربوط به Pelican را از طریق گفتگوهای Pelican در https://github.com/getpelican/pelican/discussions مطرح کنید. لطفاً ابتدا فهرست گفتگوها و مشکلات (هم باز و هم بسته) موجود را بررسی کنید تا از ارسال موضوعاتی که پیشتر پوشش داده شدهاند، خودداری شود.
اگر قصد مشارکت دارید، لطفاً مخزن Git به نشانی https://github.com/getpelican/pelican را فورک کنید، یک شاخه ویژگی جدید بسازید، تغییرات خود را اعمال کرده و یک pull request ارسال کنید. در اسرع وقت تغییرات شما بازبینی خواهد شد. لطفاً برای جزئیات بیشتر به بخش نحوه مشارکت <> مراجعه کنید.
همچنین میتوانید با ساخت پوستهها و بهبود مستندات مشارکت داشته باشید.
آیا فایل تنظیمات Pelican اجباری است؟
فایلهای پیکربندی اختیاری هستند و صرفاً راهی ساده برای پیکربندی Pelican به شمار میروند. برای عملیات پایه، امکان تعیین گزینهها هنگام فراخوانی Pelican از طریق خط فرمان وجود دارد. برای اطلاعات بیشتر pelican --help را ببینید.
تغییرات در فایل تنظیمات اعمال نمیشوند
هنگام آزمایش تنظیمات مختلف (بهویژه تنظیمات مربوط به متادیتا)، کش (caching) ممکن است تداخل ایجاد کند و تغییرات قابل مشاهده نباشند. در چنین مواردی، مطمئن شوید که کش از طریق LOAD_CONTENT_CACHE = False غیرفعال شده است یا از سوییچ خط فرمان --ignore-cache استفاده کنید.
در حال ساخت پوسته خود هستم؛ چگونه از Pygments برای برجستهسازی نحو استفاده کنم؟
ابزار Pygments تعدادی کلاس به محتوای تولیدشده اضافه میکند. این کلاسها توسط پوستهها برای استایلدهی به برجستهسازی نحو کد از طریق CSS استفاده میشوند. بهطور مشخص، میتوانید ظاهر برجستهسازی نحو خود را از طریق کلاس .highlight pre در فایل CSS پوسته سفارشیسازی کنید. برای نمونه، جهت مشاهده چگونگی استفاده از سبکهای گوناگون برای رندر کردن کد Django، از منوی کشویی انتخاب سبک در بالا سمت راست در سایت پیشنمایش پروژه Pygments به نشانی https://pygments.org/demo استفاده کنید.
میتوانید از دستورهای نمونه زیر برای تولید یک فایل CSS اولیه از یکی از سبکهای داخلی Pygments (در این مورد، "monokai") استفاده کرده و سپس فایل CSS تولیدشده را در پوسته جدید خود کپی کنید:
pygmentize -S monokai -f html -a .highlight > pygment.css cp pygment.css path/to/theme/static/css/
فراموش نکنید که فایل pygment.css خود را در فایل CSS اصلیتان import کنید.
چگونه پوسته خودم را بسازم؟
لطفاً به بخش پوستهها <#theming-pelican> مراجعه کنید.
آیا میتوانم بدون فورک کردن کل پوسته، قالبهای تکی را بازنویسی کنم؟
بله، میتوانید قالبهای موجود در پوستهای را که استفاده میکنید بازنویسی کرده یا قالبهای جدیدی را از طریق متغیر THEME_TEMPLATES_OVERRIDES بیفزایید. برای نمونه، جهت بازنویسی قالب برگه (page)، میتوانید مکان قالبهای خود را به این صورت تعریف کنید:
THEME_TEMPLATES_OVERRIDES = ["templates"]
سپس میتوانید یک قالب سفارشی در templates/page.html تعریف کنید. برای جزئیات، بخش پوستهها <#settings-themes> را ببینید.
میخواهم از Markdown استفاده کنم، اما با خطا مواجه شدم.
اگر بدون نصب کتابخانه Markdown سعی در تولید محتوای Markdown داشته باشید، ممکن است پیامی با مضمون No valid files found in content دریافت کنید. کتابخانه Markdown یک وابستگی اجباری برای Pelican نیست، بنابراین اگر محتوایی در قالب Markdown دارید، باید کتابخانه Markdown را بهطور صریح نصب کنید. میتوانید این کار را با وارد کردن دستور زیر انجام دهید (در صورت نیاز به دسترسیها، sudo را در ابتدای آن قرار دهید):
python -m pip install markdown
آیا میتوانم از متادیتای دلخواه در قالبهای خود استفاده کنم؟
بله. برای نمونه، جهت گنجاندن تاریخ ویرایش در یک نوشته Markdown، میتوان مورد زیر را در ابتدای مقاله قرار داد:
Modified: 2012-08-08
برای reStructuredText، این متادیتا مسلماً باید با یک دونقطه (colon) آغاز شود:
:Modified: 2012-08-08
سپس میتوان در قالبهایی مانند article.html از طریق زیر به این متادیتا دسترسی پیدا کرد:
{% if article.modified %}
Last modified: {{ article.modified }}
{% endif %}
اگر میخواهید متادیتا را در قالبهای خارج از زمینه مقاله (مانند base.html) بگنجانید، عبارت شرطی if باید در عوض به صورت زیر باشد:
{% if article and article.modified %}
این تنظیمات را امتحان کنید:
USE_FOLDER_AS_CATEGORY = False
PATH_METADATA = "(?P<path_no_ext>.*)\..*"
ARTICLE_URL = ARTICLE_SAVE_AS = PAGE_URL = PAGE_SAVE_AS = "{path_no_ext}.html"
چگونه قالبهای سفارشی را به ازای هر برگه اختصاص دهم؟
این کار به سادگی افزودن یک خط متادیتا به هر برگه یا مقالهای است که میخواهید قالب مخصوص به خود را داشته باشد. برای مثال، نحوه انجام این کار برای محتوا در قالب reST به این صورت است:
:template: template_name
برای محتوا در قالب Markdown:
Template: template_name
سپس کافی است مطمئن شوید پوسته (theme) شما حاوی فایل قالب مربوطه باشد (مانند template_name.html). اگر صرفاً میخواهید یک قالب سفارشی جدید را به یک پوسته موجود اضافه کنید، میتوانید آن را در پوشهای که توسط THEME_TEMPLATES_OVERRIDES مشخص شده قرار دهید (به بخش پوستهها <#settings-themes> مراجعه کنید).
چگونه میتوانم نشانی URL تولیدشده یک برگه یا مقاله خاص را بازنویسی کنم؟
متادیتای url و save_as را در هر برگه یا مقالهای که میخواهید URL تولیدشده آن را بازنویسی کنید، قرار دهید. در اینجا نمونهای از یک برگه در قالب reST آمده است:
Override url/save_as page ######################### :url: override/url/ :save_as: override/url/index.html
با این متادیتا، برگه در مسیر override/url/index.html نوشته خواهد شد و Pelican از نشانی override/url/ برای پیوند به این برگه استفاده خواهد کرد.
چگونه میتوانم از یک برگه ایستا به عنوان صفحه اصلی استفاده کنم؟
از قابلیت بازنویسی (override) ذکرشده در بالا میتوان برای تعیین یک برگه ایستا به عنوان صفحه اصلی استفاده کرد. نمونه Markdown زیر میتواند در content/pages/home.md ذخیره شود:
Title: Welcome to My Site URL: save_as: index.html Thank you for visiting. Welcome!
اگر همچنان به صفحه اصلی وبلاگ (blog index) نیاز است، میتوان با تنظیم INDEX_SAVE_AS = 'blog_index.html' برای قالب مستقیم 'index'، آن را در مکان دیگری ذخیره کرد.
چگونه میتوانم تولید خوراک (feed) را غیرفعال کنم؟
برای غیرفعال کردن تولید خوراک، تمام تنظیمات خوراک باید بر روی None تنظیم شوند. به جز سه مورد، مقدار پیشفرض تمام تنظیمات خوراک از قبل None است؛ بنابراین اگر میخواهید تولید تمام خوراکها را غیرفعال کنید، تنها کافی است تنظیمات زیر را مشخص کنید:
FEED_ALL_ATOM = None CATEGORY_FEED_ATOM = None TRANSLATION_FEED_ATOM = None AUTHOR_FEED_ATOM = None AUTHOR_FEED_RSS = None
کلمه None نباید داخل علامت نقلقول قرار گیرد. لطفاً توجه داشته باشید که None و '' یکسان نیستند.
هشداری درباره تولید خوراکها بدون تنظیم صحیح SITEURL دریافت میکنم
خوراکهای RSS و Atom نیازمند آن هستند که تمام پیوندهای URL مطلق باشند https://validator.w3.org/feed/docs/rss2.html#comments. برای تولید صحیح پیوندها در Pelican، باید SITEURL را روی مسیر کامل سایت خود تنظیم کنید.
هنگام نمایش این هشدار خوراکها همچنان تولید میشوند، اما ممکن است پیوندهای درون آنها ناقص یا معیوب باشند و بنابراین خوراک معتبر شناخته نشود.
آیا میتوانم خوراکهای Atom را مجبور به نمایش خلاصه به جای متن کامل مقاله کنم؟
اکثریت قاطع افرادی که از خوراکخوانها استفاده میکنند، ترجیح میدهند محتوا را در خود برنامهخوان مطالعه کنند تا اینکه مجبور باشند پنجره جداگانهای را در مرورگر باز کنند. عمدتاً به همین دلیل، Pelican از محدود کردن خوراکهای Atom به خلاصهها پشتیبانی نمیکند. برخلاف خوراکهای Atom، مشخصات فنی خوراک RSS فیلد جداگانهای به نام content ندارد، بنابراین Pelican بهطور پیشفرض خوراکهای RSS را تنها با خلاصه منتشر میکند (اما میتوان آن را به صورت اختیاری برای انتشار محتوای کامل در خوراکهای RSS نیز تنظیم کرد). در نتیجه، رفتار پیشفرض تولید خوراک برای کاربران یک حق انتخاب فراهم میکند: عضویت در خوراکهای Atom برای دسترسی به محتوای کامل یا خوراکهای RSS تنها برای دریافت خلاصهها.
آیا Pelican فقط برای وبلاگها مناسب است؟
خیر. Pelican را میتوان به راحتی برای ایجاد و نگهداری هر نوع وبسایت ایستایی پیکربندی کرد. این کار ممکن است نیازمند کمی سفارشیسازی پوسته و پیکربندی Pelican شما باشد. به عنوان مثال، اگر در حال ساخت وبسایت معرفی محصول هستید و نیازی به برچسبها در سایت خود ندارید، میتوانید کدهای HTML مربوطه را از پوسته حذف کنید. همچنین میتوانید تولید برگههای مربوط به برچسبها را از این طریق غیرفعال کنید:
TAGS_SAVE_AS = '' TAG_SAVE_AS = ''
برای تشخیص مطمئن اینکه آیا خروجی HTML قبل از بازنویسی تغییر کرده است یا خیر، باید بخش بزرگی از محیط تولید شامل زمینههای قالب (template contexts)، افزونههای وارد شده و غیره ذخیره و مقایسه شوند؛ دستکم در قالب یک هش (hash) که این امر خود نیازمند مدیریت ویژهٔ انواع دادههای غیرقابل هش خواهد بود، زیرا ترکیبات احتمالی بیشماری از افزونهها، صفحهبندیها و غیره وجود دارند که ممکن است به روشهای گوناگونی تغییر کنند. این فرایند به زمان پردازش، حافظه و فضای ذخیرهسازی بسیار بیشتری نیاز خواهد داشت. صرفاً نوشتن هر بارهٔ فایلها بسیار سریعتر و بسیار قابلاطمینانتر است.
با این حال، این بدان معناست که زمان ویرایش فایلها هر بار تغییر میکند، بنابراین بارگذاری مبتنی بر rsync حتی در صورتی که محتوای فایلها تغییری نکرده باشد، آنها را انتقال خواهد داد. یک راهحل ساده استفاده از گزینهٔ --checksum در دستور rsync است که موجب میشود چکسامهای فایلها به شیوهای بسیار سریعتر از آنچه Pelican انجام میداد، مقایسه شوند.
چگونه تنها زیرمجموعهای از تمام مقالهها را پردازش کنیم؟
اغلب برای اهداف اشکالزدایی مفید است که مثلاً تنها ۱۰ مقاله پردازش شوند. این کار را میتوان با مشخص کردن صریح نام فایلهای آن مقالهها در ARTICLE_PATHS انجام داد. فهرستی از چنین نام فایلهایی را میتوان با دستوری مشابه cd content; find -name '*.md' | head -n 10 به دست آورد.
ابر برچسبهای من پس از ارتقای Pelican ناپدید/خراب شده است
در راستای تلاش مداوم برای بهینهسازی و سادهسازی Pelican، تولید ابر برچسبها (tag cloud) از هستهٔ Pelican خارج شده و به یک افزونهٔ جداگانه https://github.com/pelican-plugins/tag-cloud منتقل شده است. برای اطلاعات بیشتر دربارهٔ سامانهٔ افزونههای Pelican، مستندات Plugins <#plugins> را مشاهده کنید.
از زمان ارتقای Pelican برگههای من دیگر رندر نمیشوند
برگهها (Pages) در پوستهها هم به صورت حروف کوچک pages و هم با حروف بزرگ PAGES در دسترس بودند. برای هماهنگی با بخش Templates and Variables <#templates-variables>، متغیر PAGES حذف شده است. این مشکل با بهروزرسانی پوسته جهت پیمایش روی pages به جای PAGES بهسرعت حل میشود. کافی است:
{% for pg in PAGES %}
را با چیزی شبیه به این جایگزین کنید:
{% for pg in pages %}
چگونه میتوان از تلاش Pelican برای تجزیهٔ فایلهای ایستا به عنوان محتوا جلوگیری کرد؟
تولیدکنندههای مقالهها و برگههای Pelican پیش از تولیدکنندهٔ فایلهای ایستای آن اجرا میشوند. این بدان معناست که اگر تنظیمی مشابه با پیکربندی پیشفرض داشته باشید، که در آن یک پوشهٔ منبع ایستا درون یک تنظیم *_PATHS تعریف شده باشد، تمامی فایلهایی که پسوند فایل محتوایی معتبر دارند (.html، .rst، .md و ...) قبل از آنکه به عنوان فایل ایستا در نظر گرفته شوند، به عنوان مقاله یا برگه پردازش خواهند شد.
برای دور زدن این مشکل، یا از تنظیم مناسب *_EXCLUDES استفاده کنید یا خوانندهٔ مربوطه (reader) را در صورتی که نیازی به آن ندارید، از طریق READERS غیرفعال نمایید.
چرا [نحو دلخواه Markdown] پشتیبانی نمیشود؟
پردازش Markdown مستقیماً توسط Pelican انجام نمیشود و در عوض این کار به پروژهٔ Python-Markdown https://github.com/Python-Markdown/markdown واگذار شده است که هستهٔ آن عمداً از قواعد نحو اولیهٔ Markdown پیروی میکند و نه از انبوه «طعمها» ("flavors")ی Markdown که پس از آن گسترش یافتهاند. با این حال، پروژهٔ Python-Markdown https://github.com/Python-Markdown/markdown کاملاً پیمانهای است و نحو مورد نظر شما ممکن است توسط یکی از افزونههای متعدد Markdown Extensions https://python-markdown.github.io/extensions ارائه شده باشد. از سوی دیگر، برخی کاربران افزونههایی برای Pelican ایجاد کردهاند که از نگارشهای مختلف Markdown پشتیبانی میکنند؛ بنابراین اگر میخواهید هنگام نوشتن محتوای خود از نگارش خاصی استفاده کنید، ممکن است این افزونهها بهترین گزینه باشند.
نکات
در اینجا چند نکتهٔ کاربردی دربارهٔ Pelican آورده شده است.
صفحههای ۴۰۴ سفارشی
هنگامی که یک مرورگر منبعی را درخواست میکند که وبسرور قادر به یافتن آن نیست، وبسرور معمولاً یک صفحهٔ خطای پیشفرض «پرونده یافت نشد» (404) را نمایش میدهد که اغلب ساده و نازیبا است. یکی از راههای ارائهٔ یک صفحهٔ خطا که با پوستهٔ سایت شما همخوانی داشته باشد، ایجاد یک برگهٔ ۴۰۴ سفارشی (نه یک مقاله) است؛ مانند این نمونه با فرمت Markdown که در content/pages/404.md ذخیره شده است:
Title: Not Found Status: hidden Save_as: 404.html The requested item could not be located. Perhaps you might want to check the [Archives](/archives.html)?
گام بعدی، پیکربندی وبسرور جهت نمایش این برگهٔ سفارشی به جای صفحهٔ ۴۰۴ پیشفرض آن است. برای Nginx، عبارت زیر را به بلوک location در فایل پیکربندی خود بیفزایید:
error_page 404 /404.html;
برای Apache:
ErrorDocument 404 /404.html
برای Amazon S3، ابتدا در کنسول AWS به منوی Static Site Hosting در تنظیمات باکت بروید. از آنجا:
Error Document: 404.html
اگر از GitHub https://github.com برای وبسایت Pelican خود استفاده میکنید، میتوانید وبسایتتان را بهصورت رایگان در GitHub Pages https://pages.github.com منتشر کنید. اگر وبسایت شما یک سایت کاربری یا سازمانی باشد در https://<username>.github.io و اگر یک سایت پروژه باشد در https://<username>.github.io/<repository> منتشر خواهد شد. همچنین استفاده از دامنه سفارشی با GitHub Pages https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site امکانپذیر است.
دو روش برای انتشار یک وبسایت در GitHub Pages وجود دارد https://docs.github.com/en/pages/getting-started-with-github-pages/configuring-a-publishing-source-for-your-github-pages-site:
- 1.
- انتشار از یک شاخه: دستور pelican را بهصورت محلی اجرا کرده و دایرکتوری خروجی را به یک شاخه خاص از مخزن GitHub خود push کنید. سپس GitHub محتویات این شاخه را در وبسایت GitHub Pages شما منتشر خواهد کرد.
- 2.
- انتشار با یک جریان کاری سفارشی GitHub Actions: کافی است فایلهای منبع وبسایت Pelican خود را به شاخه پیشفرض مخزن GitHub خود push کرده و از یک جریان کاری (workflow) سفارشی GitHub Actions بخواهید که pelican را برای شما اجرا کند تا دایرکتوری خروجی تولید و در وبسایت GitHub Pages منتشر شود. به این ترتیب نیازی به اجرای محلی pelican نخواهید داشت. حتی میتوانید فایلهای منبع وبسایت خود را با استفاده از رابط وب GitHub ویرایش کنید و هر تغییری که commit کنید منتشر خواهد شد.
انتشار یک وبسایت پروژه در GitHub Pages از یک شاخه
برای انتشار یک وبسایت Pelican بهصورت یک صفحه پروژه (Project Page)، باید محتوای دایرکتوری output تولیدشده توسط Pelican را به شاخه gh-pages یک مخزن در GitHub دستور push کنید.
ابزار عالی ghp-import https://github.com/davisp/ghp-import که با pip قابل نصب است، این فرایند را بسیار آسان میکند.
بهعنوان مثال، اگر منبع وبسایت Pelican شما در یک مخزن GitHub قرار دارد، و میخواهید آن وبسایت Pelican را در قالب Project Pages در این مخزن منتشر کنید، میتوانید از دستورهای زیر استفاده کنید:
$ pelican content -o output -s pelicanconf.py $ ghp-import output -b gh-pages $ git push origin gh-pages
دستور ghp-import output شاخه محلی gh-pages را با محتوای دایرکتوری output بهروزرسانی میکند (در صورتی که شاخه از قبل وجود نداشته باشد، آن را ایجاد میکند). دستور git push origin gh-pages شاخه دوردست gh-pages را بهروز کرده و عملاً وبسایت Pelican را منتشر میسازد.
نکته:
انتشار یک وبسایت کاربری در GitHub Pages از یک شاخه
برای انتشار یک وبسایت Pelican در قالب صفحات کاربری (User Pages)، باید محتوای دایرکتوری output تولیدشده توسط Pelican را به شاخه main مخزن <username>.github.io خود در GitHub ارسال (push) کنید.
بار دیگر، میتوانید از ابزار ghp-import بهره ببرید:
$ pelican content -o output -s pelicanconf.py $ ghp-import output -b gh-pages $ git push git@github.com:elemoine/elemoine.github.io.git gh-pages:main
دستور git push شاخه محلی gh-pages (که بهتازگی توسط دستور ghp-import بهروز شده است) را به شاخه main در مخزن elemoine.github.io در GitHub ارسال (push) میکند.
نکته:
گزینه دیگر برای انتشار بهصورت User Pages، تولید فایلهای خروجی در دایرکتوری ریشه پروژه است.
برای مثال، پوشه اصلی پروژه شما <username>.github.io است و میتوانید پروژه Pelican را در یک زیردایرکتوری با نام Pelican ایجاد کنید. سپس از داخل پوشه Pelican میتوانید اجرا کنید:
$ pelican content -o .. -s pelicanconf.py
اکنون میتوانید کل پروژه <username>.github.io را به شاخه main مخزن GitHub خود push کنید:
$ git push origin main
(با فرض اینکه origin روی مخزن دوردست شما تنظیم شده باشد).
انتشار در GitHub Pages با استفاده از یک جریان کاری سفارشی GitHub Actions
وبسایتهای مبتنی بر Pelican میتوانند از طریق یک جریان کاری سفارشی https://github.com/getpelican/pelican/blob/main/.github/workflows/github_pages.yml در GitHub Pages منتشر شوند. برای استفاده از آن:
- 1.
- فعالسازی GitHub Pages در مخزن خود: به بخش Settings → Pages بروید و برای تنظیم Source گزینه GitHub Actions را انتخاب کنید.
- 2.
- یک فایل .github/workflows/pelican.yml را با این محتوا به مخزن خود commit کنید:
name: Deploy to GitHub Pages
on:
push:
branches: ["main"]
workflow_dispatch:
jobs:
deploy:
uses: "getpelican/pelican/.github/workflows/github_pages.yml@main"
permissions:
contents: "read"
pages: "write"
id-token: "write"
with:
settings: "publishconf.py"
ممکن است بخواهید @main را با شناسه (ID) یک commit خاص در این مخزن جایگزین کنید تا نسخه جریان کاری قابل استفاده مجدد را تثبیت (pin) کنید: uses: getpelican/pelican/.github/workflows/github_pages.yml@<COMMIT_ID>. اگر این کار را انجام دهید، ممکن است بخواهید ترتیبی دهید که Dependabot با انتشار نسخههای جدید این جریان کاری، pull requestهای خودکاری برای بهروزرسانی آن شناسه commit برای شما ارسال کند، به این صورت:
# .github/dependabot.yml
version: 2
updates:
- package-ecosystem: "github-actions"
directory: "/"
schedule:
interval: "monthly"
برای اطلاعات بیشتر، مستندات GitHub درباره استفاده از Dependabot برای بهروز نگهداشتن Actionهای خود را ببینید https://docs.github.com/en/code-security/dependabot/working-with-dependabot/keeping-your-actions-up-to-date-with-dependabot.
- 3.
- به برگه Actions در مخزن خود بروید (https://github.com/<username>/<repository>/actions)؛ در آنجا باید اقدام (action) Deploy to GitHub Pages را در حال اجرا ببینید.
- 4.
- پس از اتمام این اقدام، باید وبسایت Pelican خود را که در نشانی GitHub Pages مخزن شما مستقر شده است مشاهده کنید: https://<username>.github.io برای یک سایت کاربری یا سازمانی، یا https://<username>.github.io/<repository>> برای یک سایت پروژه.
نکات:
- نیازی به تنظیم SITEURL یا FEED_DOMAIN در تنظیمات Pelican خود ندارید: جریان کاری این مقادیر را بهدرستی برای شما تنظیم خواهد کرد
- نیازی به commit کردن دایرکتوری --output / OUTPUT_PATH (output/) در git ندارید: جریان کاری، دستور pelican را روی GitHub Actions اجرا میکند تا دایرکتوری خروجی را برای شما بسازد
برای اطلاعات بیشتر، مستندات GitHub در مورد جریانهای کاری با قابلیت استفاده مجدد (reusable workflows) را ببینید https://docs.github.com/en/actions/using-workflows/reusing-workflows.
هنگام فراخوانی جریان کاری، تعدادی ورودی اختیاری را میتوان به بلوک with: اضافه کرد، برای مثال:
with: settings: "publishconf.py" requirements: "pelican[markdown] typogrify" theme: "https://github.com/seanh/sidecar.git" python: "3.12"
در ادامه فهرست کامل ورودیهای جریان کاری آمده است:
| نام | الزامی | توضیحات | نوع | پیشفرض |
| settings | بله | مسیر فایل تنظیمات Pelican (گزینه --settings در pelican)، برای مثال: "publishconf.py" | string | |
| requirements | خیر | پیشنیازهای پایتون برای نصب، برای مثال جهت فعالسازی markdown و typogrify: "pelican[markdown] typogrify" یا در صورت داشتن فایل پیشنیازها: "-r requirements.txt" | string | "pelican" |
| output-path | خیر | محل ذخیره فایلهای خروجی تولیدشده (گزینه --output در pelican) | string | "output/" |
| theme | خیر | نشانی مخزن GitHub یک تم سفارشی برای استفاده، برای مثال: "https://github.com/seanh/sidecar.git" | string | "" |
| python | خیر | نسخه پایتون مورد استفاده برای ساخت سایت، برای مثال: "3.12" (جهت استفاده از جدیدترین نسخه پایتون ۳.۱۲ که سریعتر است) یا "3.12.1" (برای استفاده از یک نسخه دقیق که کندتر است) | string | "3.12" |
| siteurl | خیر | نشانی پایه وبسایت شما (تنظیم SITEURL در Pelican). در صورت عدم ارسال، مقدار پیشفرض آن نشانی سایت GitHub Pages شما خواهد بود که در اغلب موارد صحیح است. | string | نشانی سایت GitHub Pages شما. |
| feed_domain | خیر | دامنهای که به ابتدای نشانیهای خوراک اضافه میشود (تنظیم FEED_DOMAIN در Pelican). در صورت عدم ارسال، مقدار پیشفرض آن نشانی وبسایت GitHub Pages شما خواهد بود که در اکثر موارد صحیح است. | string | نشانی سایت GitHub Pages شما. |
| deploy | خیر | برای تعیین اینکه آیا سایت در GitHub Pages مستقر شود یا خیر استفاده میشود. این گزینه زمانی بسیار کاربردی است که بخواهید تغییری در وبسایت خود را پیش از استقرار، در یک pull request آزمایش کنید. | bool | true |
| اگر میخواهید پیش از استقرار در گیتهاب، ساخت (build) خود را در یک pull request آزمایش کنید، گردشکار (workflow) شما ممکن است چیزی شبیه به این باشد: | ||||
| 0.0 | ||||
| 3.5 | ||||
| name: Build and Deploy Site | ||||
| on: | ||||
| push: | ||||
| branches: ["main"] | ||||
| pull_request: | ||||
| branches: ["main"] | ||||
| workflow_dispatch: | ||||
| inputs: | ||||
| deploy: | ||||
| required: false | ||||
| default: true | ||||
| description: "Whether to deploy the site. If checked, then build the site and deploy it. If not checked, then just test that the site builds successfully but don't deploy anything." | ||||
| type: boolean | ||||
| jobs: | ||||
| deploy: | ||||
| uses: "getpelican/pelican/.github/workflows/github_pages.yml@main" | ||||
| permissions: | ||||
| id-token: write | ||||
| contents: read | ||||
| pages: write | ||||
| with: | ||||
| settings: "publishconf.py" | ||||
| requirements: "-r requirements.txt" | ||||
| deploy: ${{ (github.event_name == 'workflow_dispatch' && inputs.deploy == true) || (github.event_name == 'push' && github.ref_type == 'branch' && github.ref_name == github.event.repository.default_branch) }} | ||||
| 168u | ||||
| 168u | ||||
| بخش on گردشکار رویدادهایی را مشخص میکند که گردشکار را راهاندازی (trigger) خواهند کرد. در این مثال، گردشکار با push به شاخه اصلی (main)، pull requestها به شاخه اصلی و اجراهای دستی گردشکار اجرا خواهد شد. | ||||
| workflow_dispatch متغیر بولیِ deploy را بهطور پیشفرض برابر با true تعریف میکند. این بدان معناست که اگر گردشکار را بهصورت دستی اجرا کنید، سایت مستقر خواهد شد. | ||||
| ورودی deploy برای کار (job) از مجموعهای از متغیرهای استاندارد گردشکار گیتهاب برای کنترل زمانهایی که deploy مقدار true یا false دارد استفاده میکند (میتوانید آن را بر اساس نیازهای خود سفارشیسازی کنید). | ||||
| در این مثال، مقدار deploy در صورتی true خواهد بود که رویداد از نوع push به شاخه اصلی (یا ادغام به main از طریق یک PR) یا اجرای دستی گردشکار باشد. اگر رویداد یک pull request باشد، مقدار deploy برابر با false خواهد بود و تنها یک آرتیفکت برای سایت ساخته خواهد شد. | ||||
| هشدارهای «محتوای ناامن» ("Insecure content") از سوی مرورگرها | ||||
| اگر سایت شما از https:// استفاده میکند و به دلیل مسدود شدن درخواستهای شبکه (برای مثال برای فایلهای CSS) توسط مرورگر به علت «محتوای ناامن» ("insecure content") دچار مشکل شده است، ممکن است به این دلیل باشد که GitHub Pages در حال تولید نشانیهای اینترنتی http:// برای سایت شماست. | ||||
| برای رفع این مشکل، به تنظیمات مخزن سایت خود بروید و گزینه Enforce HTTPS را فعال کنید: | ||||
| به Settings → Pages بروید و Enforce HTTPS را علامت بزنید. | ||||
| سپس گردشکار را دوباره اجرا کنید تا سایت شما مجدداً مستقر شود. | ||||
| همچنین، میتوانید از تنظیمات siteurl و feed_domain در گردشکار استفاده کنید. | ||||
| صفحههای ۴۰۴ سفارشی | ||||
| همانطور که در مستندات مربوطه در گیتهاب https://help.github.com/articles/custom-404-pages ذکر شده است، GitHub Pages صفحه ۴۰۴ سفارشی شرحدادهشده در بالا را نمایش خواهد داد. | ||||
| بهروزرسانی سایت در هر کامیت | ||||
| برای بهروزرسانی خودکار سایت Pelican خود با هر commit، میتوانید یک قلاب post-commit ایجاد کنید. برای مثال، میتوانید عبارت زیر را به .git/hooks/post-commit بیفزایید: | ||||
| 0.0 | ||||
| 3.5 | ||||
| pelican content -o output -s pelicanconf.py && ghp-import output && git push origin gh-pages | ||||
| 168u | ||||
| 168u | ||||
| کپی فایلهای ایستا به ریشه سایت | ||||
| برای استفاده از یک دامنه سفارشی https://help.github.com/articles/setting-up-a-custom-domain-with-pages با | ||||
| GitHub Pages، باید دامنه سایت خود (مانند | ||||
| blog.example.com) را درون یک فایل CNAME در ریشه سایت قرار دهید. برای این | ||||
| کار، دایرکتوری content/extra/ را بسازید و یک فایل CNAME به آن اضافه کنید. | ||||
| سپس از تنظیم STATIC_PATHS استفاده کنید تا به Pelican اعلام کنید این فایل را در | ||||
| دایرکتوری خروجی کپی کند. برای مثال: | ||||
| 0.0 | ||||
| 3.5 | ||||
| STATIC_PATHS = ['images', 'extra/CNAME'] | ||||
| EXTRA_PATH_METADATA = {'extra/CNAME': {'path': 'CNAME'},}` | ||||
| 168u | ||||
| 168u | ||||
| نکته: حتی در ویندوز نیز از اسلشهای رو به جلو، /، استفاده کنید. | ||||
| همچنین میتوانید از سازوکار EXTRA_PATH_METADATA برای قرار دادن یک | ||||
| favicon.ico یا robots.txt در ریشه هر سایتی استفاده کنید. | ||||
| نحوه افزودن ویدیوهای YouTube یا Vimeo | ||||
| سادهترین روش این است که کد جاسازی (embed) ویدیو را از این سایتها | ||||
| مستقیماً در محتوای مبدأ خود جایگذاری (paste) کنید. | ||||
| بهعنوان راهکاری دیگر، میتوانید از افزونههای Pelican مانند liquid_tags، | ||||
| pelican_youtube یا pelican_vimeo برای جاسازی ویدیوها در محتوای خود استفاده کنید. | ||||
| علاوه بر این، زبانهای نشانهگذاری مانند reST و Markdown دارای افزونههایی هستند که به شما امکان میدهند | ||||
| ویدیوها را در نشانهگذاری جاسازی کنید. میتوانید از دستورالعمل ویدیوی reST در https://gist.github.com/dbrgn/2922648 برای reST یا افزونه mdx_video در https://github.com/italomaia/mdx-video برای Markdown استفاده کنید. | ||||
| توسعه محلی با استفاده از SSL | ||||
| در اینجا نحوه راهاندازی سرور محلی pelican برای پشتیبانی از SSL آمده است. | ||||
| ابتدا با استفاده از openssl یک کلید و گواهی خودامضا (self-signed) بسازید (این کار فایلهای cert.pem و key.pem را ایجاد میکند): | ||||
| 0.0 | ||||
| 3.5 | ||||
| $ openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes | ||||
| 168u | ||||
| 168u | ||||
| و از این دستور برای راهاندازی سرور استفاده کنید (سرور از داخل دایرکتوری output شما اجرا میشود): | ||||
| 0.0 | ||||
| 3.5 | ||||
| python -m pelican.server 8443 --key=../key.pem --cert=../cert.pem | ||||
| 168u | ||||
| 168u | ||||
| اگر از develop-server.sh استفاده میکنید، این خطوط را به بالای آن اضافه کنید: | ||||
| 0.0 | ||||
| 3.5 | ||||
| CERT="$BASEDIR/cert.pem" | ||||
| KEY="$BASEDIR/key.pem" | ||||
| 168u | ||||
| 168u | ||||
| و خط pelican.server را بهصورت زیر تغییر دهید: | ||||
| 0.0 | ||||
| 3.5 | ||||
| $PY -m pelican.server $port --ssl --cert="$CERT" --key="$KEY" & | ||||
| 168u | ||||
| روشهای زیادی برای مشارکت در Pelican وجود دارد. شما میتوانید مستندات را بهبود دهید، ویژگیهای ناموجود را اضافه کنید، و باگها را برطرف سازید (یا صرفاً آنها را گزارش کنید). همچنین میتوانید با بازبینی و ارسال نظر درباره گزارشهای مشکل موجود https://github.com/getpelican/pelican/issues کمک کنید. | ||||
| در ساخت انشعاب (fork) از Pelican و ارسال یک issue یا pull request در GitHub درنگ نکنید. هنگام انجام این کار، لطفاً راهنماهای زیر را مد نظر داشته باشید. | ||||
| ثبت گزارش مشکلات (Filing issues) | ||||
| 0.0 | ||||
| • 2 | ||||
| پیش از آنکه issue جدیدی ارسال کنید، ابتدا سعی کنید راهنمایی بخواهید. | ||||
| • 2 | ||||
| اگر مصمم به ایجاد یک issue جدید هستید، ابتدا در بحثهای Pelican https://github.com/getpelican/pelican/discussions | ||||
| و issueهای موجود https://github.com/getpelican/pelican/issues (باز و بسته) جستجو کنید تا ببینید آیا پیشتر به پرسش شما پاسخ داده شده است یا خیر. | ||||
| 168u | ||||
| نحوه دریافت راهنمایی (How to get help) | ||||
| پیش از آنکه درخواست راهنمایی کنید، لطفاً مطمئن شوید اقدامات زیر را انجام دادهاید: | ||||
| 0.0 | ||||
| 1. 3 | ||||
| مستندات https://docs.getpelican.com را بهطور کامل و دقیق بخوانید. اگر عجله دارید، دستکم از کادر جستجو که در بالا سمت چپ صفحات مستندات https://docs.getpelican.com تعبیه شده است استفاده کنید. مطمئن شوید مستندات مربوط به همان نگارش Pelican که استفاده میکنید را میخوانید. | ||||
| 2. 3 | ||||
| از یک موتور جستجو (مانند DuckDuckGo یا Google) برای یافتن راهحلی برای مشکل خود استفاده کنید. شاید فردی پیشتر راهحلی یافته باشد، مثلاً در قالب یک افزونه (plugin) https://docs.getpelican.com/en/latest/plugins.html یا ترکیب خاصی از تنظیمات. | ||||
| 3. 3 | ||||
| تلاش کنید مشکل را در یک محیط تمیز بازتولید کنید و مطمئن شوید از موارد زیر استفاده میکنید: | ||||
| 168u | ||||
| 0.0 | ||||
| • 2 | ||||
| جدیدترین انتشار Pelican (یا یک کلون Git بهروز از شاخه main در Pelican) | ||||
| • 2 | ||||
| جدیدترین نگارش کتابخانههای مورد استفاده Pelican | ||||
| • 2 | ||||
| بدون هیچ افزونهای یا تنها با افزونههای مرتبط با مشکل | ||||
| 168u | ||||
| نکته: شایعترین منشأ مشکلات، ناهنجاریها در (۱) تمها، (۲) افزونهها، (۳) فایلهای تنظیمات، و (۴) اسکریپتهای پوششی خودکارسازی make/invoke هستند. | ||||
| اگر هنگام استفاده از مراحل زیر برای تولید سایت خود نتوانستید مشکل را بازتولید کنید، تقریباً بهطور قطع مشکل از یکی از عناصر ذکرشده در بالاست (و نه خود Pelican): | ||||
| 0.0 | ||||
| 3.5 | ||||
| cd ~/projects/your-site | ||||
| git clone https://github.com/getpelican/pelican ~/projects/pelican | ||||
| pelican content -s ~/projects/pelican/samples/pelican.conf.py -t ~/projects/pelican/pelican/themes/notmyidea | ||||
| 168u | ||||
| 168u | ||||
| اگر توانستید سایت خود را با مراحل بالا بدون مشکل ایجاد کنید، بعید است مشکل ناشی از خود Pelican باشد؛ بنابراین لطفاً به جای مطرح کردن موضوع با جامعه اصلی Pelican، با نگهدارندگان تم یا افزونههایی که استفاده میکنید تماس بگیرید. | ||||
| اگر با وجود تلاشهای فوق همچنان نتوانستید مشکل خود را برطرف کنید، حتماً اطلاعات زیر را در پرسش خود بگنجانید، ترجیحاً در قالب پیوندهایی به محتوای بارگذاریشده در یک سرویس اشتراک متن (paste service) https://dpaste.com، مخزن GitHub، یا هر مکان دیگر با دسترسی عمومی: | ||||
| 0.0 | ||||
| • 2 | ||||
| شرح دهید از چه نگارشی از Pelican استفاده میکنید (خروجی pelican --version یا هش کامیت HEAD در صورتی که مخزن را کلون کردهاید) و دقیقاً چگونه آن را نصب کردهاید (دستور کاملی که استفاده کردهاید، مثلاً python -m pip install pelican). | ||||
| • 2 | ||||
| اگر به دنبال راهی برای رسیدن به یک نتیجه نهایی خاص هستید، توضیحی با جزئیات از اینکه نتیجه نهایی چگونه باید باشد آماده کنید (ترجیحاً در قالب یک تصویر یا ماکت صفحه) و به تفصیل شرح دهید که تاکنون برای رسیدن به آن چه کردهاید. | ||||
| • 2 | ||||
| اگر در تلاش برای رفع یک مشکل هستید، شرح دقیقی از نحوه بازتولید مشکل آماده کنید. اگر مشکل بهسادگی قابل بازتولید نباشد، اشکالزدایی آن توسط توسعهدهندگان یا داوطلبان امکانپذیر نخواهد بود. تنها حداقل مراحل لازم برای بازتولید را توضیح دهید (بدون افزونههای اضافی و غیره). | ||||
| • 2 | ||||
| فایل تنظیمات خود یا هر کد سفارشی دیگری را که به دیگران اجازه بازتولید مشکل یا بررسی تلاشهای پیشین شما برای دستیابی به نتیجه مورد نظر را میدهد، بارگذاری کنید. | ||||
| • 2 | ||||
| گزارشهای خروجی و ردگیریهای پشته (backtraces) تفصیلی و کامل را بارگذاری کنید (به یاد داشته باشید که پرچم --debug را اضافه کنید: pelican --debug content [...]) | ||||
| 168u | ||||
| پس از انجام مقدمات بالا، میتوانید پرسش خود را به عنوان یک مبحث جدید در بحثهای Pelican https://github.com/getpelican/pelican/discussions ارسال کنید. به خاطر داشته باشید تمامی اطلاعات آمادهشده را ضمیمه کنید. | ||||
| مشارکت در کد (Contributing code) | ||||
| پیش از ارسال هرگونه مشارکت، لطفاً پرسوجو کنید که آیا تغییر مورد نظر پذیرفته خواهد شد یا خیر، تا زمان زیادی را صرف کاری نکنید که به دلیلی مشخص رد شود. همچنین در نظر بگیرید که آیا ویژگی جدید شما بهتر است در قالب یک افزونه https://docs.getpelican.com/en/latest/plugins.html پیادهسازی شود یا خیر — برای تصمیمگیری در این مورد میتوانید درخواست راهنمایی کنید. | ||||
| همچنین اگر قصد دارید برای موردی که هنوز issueای برای آن وجود ندارد یک pull request ارسال کنید، نیازی نیست ابتدا یک issue جدید ایجاد کرده و بلافاصله یک pull request برای بستن آن ارسال کنید. میتوانید pull request را به تنهایی ارسال کنید. | ||||
| استفاده از Git و GitHub (Using Git and GitHub) | ||||
| 0.0 | ||||
| • 2 | ||||
| یک شاخه جدید مخصوص به تغییر خود ایجاد کنید https://github.com/getpelican/pelican/wiki/Git-Tips#making-your-changes (به جای ثبت کامیتها مستقیماً در شاخه main). | ||||
| • 2 | ||||
| چندین رفع باگ یا ویژگی نامرتبط را در یک شاخه یا pull request قرار ندهید. | ||||
| برای نمونه، اگر روی یک ویژگی جدید کار میکنید و متوجه رفع باگی شدید که به ویژگی جدید شما نیازی ندارد، یک شاخه و pull request کاملاً مجزا برای آن رفع باگ بسازید. به همین ترتیب، هرگونه تغییر پیشنهادی برای اصلاح سبک قالببندی کد باید در یک pull request کاملاً جداگانه قرار گیرد. | ||||
| • 2 | ||||
| یک فایل RELEASE.md در ریشه پروژه اضافه کنید که نوع انتشار (major، minor، patch) و خلاصهای از تغییرات را که به عنوان مدخل سیاهه تغییرات (changelog) انتشار استفاده میشود، شامل شود. برای نمونه: | ||||
| 2.0 | ||||
| 3.5 | ||||
| Release type: minor | ||||
| Reload browser window upon changes to content, settings, or theme | ||||
| 168u | ||||
| 168u | ||||
| • 2 | ||||
| پیش از کامیت کردن، با استفاده از git diff --check فاصلههای خالی غیرضروری را بررسی کنید. | ||||
| • 2 | ||||
| خط نخست پیام کامیت شما باید با یک فعل در زمان حال آغاز شود، ۵۰ نویسه یا کمتر باشد، و در صورت لزوم شماره issue(های) مرتبط را در بر گیرد. | ||||
| نمونه: Ensure proper PLUGIN_PATH behavior. Refs #428. اگر کامیت یک گزارش باگ موجود را بهطور کامل برطرف میکند، لطفاً از نحو Fixes #585 یا Fix #585 استفاده کنید (تا پس از ادغام PR، issue مربوطه بهطور خودکار بسته شود). | ||||
| • 2 | ||||
| پس از خط اول پیام کامیت، یک خط خالی و سپس شرحی مفصلتر (در صورت ارتباط) اضافه کنید. | ||||
| • 2 | ||||
| کامیتهای خود را فشرده (squash) کنید https://github.com/getpelican/pelican/wiki/Git-Tips#squashing-commits تا کامیتهای ادغام حذف شوند و از یک تاریخچه کامیت تمیز و خوانا اطمینان حاصل شود. | ||||
| • 2 | ||||
| پس از ارسال یک pull request، سیستم یکپارچهسازی مداوم (CI) مجموعه آزمونها را روی تمام نگارشهای پشتیبانیشده Python اجرا کرده و انطباق سبک کد را بررسی میکند. اگر هر یک از این بررسیها با شکست مواجه شد، باید آنها را اصلاح کنید. (اگر آزمونها در سیستم CI با خطا مواجه شدند اما به صورت محلی موفقیتآمیز بودند، مطمئن شوید اجرای محلی آزمونها هیچ آزمونی را نادیده نگرفته باشد.) | ||||
| 0.0 | ||||
| • 2 | ||||
| به استانداردهای شیوهنامهٔ کدنویسی پروژه پایبند باشید. ببینید: محیط توسعه https://docs.getpelican.com/en/latest/contribute.html#setting-up-the-development-environment | ||||
| • 2 | ||||
| اطمینان حاصل کنید که کد شما با نسخههای رسماً پشتیبانیشدهٔ Python سازگار است https://devguide.python.org/versions/#versions. | ||||
| • 2 | ||||
| برای تغییرات خود مستندات و آزمونها را اضافه کنید. ویژگیهای فاقد مستندات و بدون آزمون | ||||
| پذیرفته نخواهند شد. | ||||
| • 2 | ||||
| تمام آزمونها https://docs.getpelican.com/en/latest/contribute.html را روی تمام نسخههای Python که توسط Pelican پشتیبانی میشوند اجرا کنید | ||||
| تا مطمئن شوید چیزی تصادفاً از کار نیفتاده است. | ||||
| 168u | ||||
| صفحهٔ نکات Git ما https://github.com/getpelican/pelican/wiki/Git-Tips را بررسی کنید یا اگر به کمک نیاز دارید | ||||
| یا دربارهٔ این دستورالعملها سؤالی دارید، درخواست راهنمایی کنید. | ||||
| راهاندازی محیط توسعه | ||||
| اگرچه راههای بسیاری برای راهاندازی محیط توسعه وجود دارد، دستورالعملهای زیر | ||||
| از Pip https://pip.pypa.io و PDM https://pdm.fming.dev/latest بهره میگیرند. این ابزارها مدیریت | ||||
| محیطهای مجازی را برای پروژههای مجزای Python که از یکدیگر ایزوله هستند تسهیل میکنند | ||||
| تا بتوانید برای هر کدام از بستهها (و نسخههای بستهٔ) متفاوتی استفاده کنید. | ||||
| لطفاً توجه داشته باشید که برای توسعهٔ Pelican به Python >=3.9 نیاز است. | ||||
| (اختیاری) اگر ترجیح میدهید PDM https://pdm.fming.dev/latest/#installation را یک بار برای استفاده در چندین پروژه نصب کنید، | ||||
| میتوانید آن را از طریق زیر نصب کنید: | ||||
| 0.0 | ||||
| 3.5 | ||||
| curl -sSL https://pdm.fming.dev/install-pdm.py | python3 - | ||||
| 168u | ||||
| 168u | ||||
| مرورگر وب خود را به سمت مخزن Pelican https://github.com/getpelican/pelican باز کرده و دکمهٔ Fork | ||||
| در بالا سمت راست را بزنید. سپس سورس فورک خود را clone کرده و پروژهٔ بالادست (upstream) را | ||||
| به عنوان یک Git remote اضافه کنید: | ||||
| 0.0 | ||||
| 3.5 | ||||
| mkdir ~/projects | ||||
| git clone https://github.com/YOUR_USERNAME/pelican.git ~/projects/pelican | ||||
| cd ~/projects/pelican | ||||
| git remote add upstream https://github.com/getpelican/pelican.git | ||||
| 168u | ||||
| 168u | ||||
| اگرچه PDM میتواند محیطهای مجازی را به صورت پویا ایجاد و مدیریت کند، ما قصد داریم | ||||
| یک محیط مجازی را به صورت دستی ایجاد و فعال کنیم: | ||||
| 0.0 | ||||
| 3.5 | ||||
| mkdir ~/virtualenvs && cd ~/virtualenvs | ||||
| python3 -m venv pelican | ||||
| source ~/virtualenvs/pelican/*/activate | ||||
| 168u | ||||
| 168u | ||||
| وابستگیهای مورد نیاز را نصب کرده و پروژه را راهاندازی کنید: | ||||
| 0.0 | ||||
| 3.5 | ||||
| python -m pip install invoke | ||||
| invoke setup | ||||
| 168u | ||||
| 168u | ||||
| اکنون محیط محلی شما باید آماده به کار باشد! | ||||
| توسعه | ||||
| پس از اینکه Pelican برای توسعهٔ محلی راهاندازی شد، یک شاخهٔ موضوعی (topic branch) برای | ||||
| رفع باگ یا قابلیت مورد نظر خود بسازید: | ||||
| 0.0 | ||||
| 3.5 | ||||
| git checkout -b name-of-your-bugfix-or-feature | ||||
| 168u | ||||
| 168u | ||||
| اکنون میتوانید تغییرات مورد نظر را در Pelican، مستندات آن و/یا سایر بخشهای پروژه | ||||
| ایجاد کنید. | ||||
| راهاندازی git blame (اختیاری) | ||||
| دستور git blame خطوط یک فایل را با اطلاعات مربوط به pull request که آخرین بار | ||||
| آن را تغییر داده نشانهگذاری میکند. تغییرات سطحی و گسترده (مانند قالببندی) میتوانند این | ||||
| اطلاعات را کمفایدهتر کنند؛ بنابراین ما فهرستی از چنین تغییراتی نگه میداریم تا نادیده گرفته شوند. دستور | ||||
| زیر را برای اعمال این تنظیم در مخزن خود اجرا کنید، و اگر میخواهید این تنظیم برای تمام | ||||
| مخازن اعمال شود، --global را اضافه کنید: | ||||
| 0.0 | ||||
| 3.5 | ||||
| git config blame.ignoreRevsFile .git-blame-ignore-revs | ||||
| 168u | ||||
| 168u | ||||
| همانطور که در مقالهای مفید https://www.michaelheap.com/git-ignore-rev دربارهٔ git blame اشاره شده است، تنظیمات | ||||
| مرتبط دیگری نیز وجود دارند که ممکن است برای شما سودمند باشند: | ||||
| 0.0 | ||||
| 3.5 | ||||
| # Add `?` to any lines that have had a commit skipped using --ignore-rev | ||||
| git config --global blame.markIgnoredLines true | ||||
| # Add `*` to any lines that were added in a skipped commit and can not be attributed | ||||
| git config --global blame.markUnblamableLines true | ||||
| 168u | ||||
| هر بار که در Pelican تغییراتی ایجاد میکنید، دو کار در رابطه با | ||||
| آزمونها باید انجام دهید: بررسی اینکه آزمونهای موجود با موفقیت سپری شوند، و افزودن آزمون برای هر قابلیت جدید | ||||
| یا رفع باگ. آزمونها در pelican/tests قرار دارند و میتوانید آنها را | ||||
| از این طریق اجرا کنید: | ||||
| 0.0 | ||||
| 3.5 | ||||
| invoke tests | ||||
| 168u | ||||
| 168u | ||||
| (برای اطلاعات بیشتر درباره Invoke، دستور invoke -l را برای فهرست کردن وظایف اجرا کنید یا | ||||
| برای مشاهده مستندات به https://pyinvoke.org مراجعه نمایید.) | ||||
| علاوه بر اجرای مجموعه آزمونها، مهم است که مطمئن شوید هر خطی که تغییر | ||||
| دادهاید با شیوهنامه نگارش کد مطابقت داشته باشد. میتوانید این مورد را از این طریق بررسی کنید: | ||||
| 0.0 | ||||
| 3.5 | ||||
| invoke lint | ||||
| 168u | ||||
| 168u | ||||
| اگر در خطوطی که تغییر دادهاید موارد نقض شیوهنامه کد یافت شد، آن خطوط را اصلاح کرده | ||||
| و دستور lint بالا را مجدداً اجرا کنید تا تمام آنها برطرف شوند. نیازی به رسیدگی به | ||||
| موارد نقض شیوهنامه (در صورت وجود) برای خطوط کدی که به آنها دست نزدهاید نیست. | ||||
| پس از اعمال تغییرات و اجرای آزمونها، ممکن است با شکست آزمونی مواجه شوید | ||||
| مبنی بر اینکه "some generated files differ from the expected functional tests | ||||
| output." (برخی فایلهای تولیدشده با خروجی آزمونهای کارکردیِ مورد انتظار تفاوت دارند). اگر تغییراتی ایجاد کردهاید که بر خروجی HTML تولیدشده توسط | ||||
| Pelican اثر میگذارد، و با توجه به ماهیت تغییرات شما، تغییرات در آن خروجی مورد انتظار و درست | ||||
| تلقی میشود، باید خروجی استفادهشده توسط آزمونهای کارکردی را بهروزرسانی کنید. | ||||
| برای این کار، مطمئن شوید هر دو لوکال en_EN.utf8 و | ||||
| fr_FR.utf8 را نصب دارید، و سپس دستور زیر را اجرا کنید: | ||||
| 0.0 | ||||
| 3.5 | ||||
| invoke update-functional-tests | ||||
| 168u | ||||
| 168u | ||||
| همچنین ممکن است متوجه شوید برخی از آزمونها به دلیل نصب نبودن یک وابستگی (مانند | ||||
| Pandoc) نادیده گرفته شدهاند. این امر لزوماً به این معنا نیست که این آزمونها | ||||
| با موفقیت سپری شدهاند؛ شما باید حداقل بررسی کنید که آزمونهای نادیده گرفتهشده تحت تأثیر | ||||
| تغییرات شما قرار نگرفته باشند. | ||||
| شما باید مجموعه آزمونها را تحت هر یک از نسخههای پشتیبانیشدهٔ Python اجرا کنید. | ||||
| این کار به بهترین نحو با ایجاد یک محیط Python جداگانه برای هر نسخه انجام میشود. | ||||
| ابزار Tox https://tox.readthedocs.io/en/latest ابزاری مفید برای خودکارسازی اجرای آزمونها داخل محیطهای virtualenv | ||||
| است. | ||||
| اجرای گزارش پوشش کد | ||||
| در صورتی که کد مورد آزمون قرار گیرد، احتمال بیشتری دارد که پایدار و مستحکم باقی بماند. ابزار Coverage https://github.com/nedbat/coveragepy کتابخانهای است که | ||||
| میزان آزموده شدن کد را میسنجد. برای اجرای آن: | ||||
| 0.0 | ||||
| 3.5 | ||||
| invoke coverage | ||||
| 168u | ||||
| 168u | ||||
| این دستور پوشش کلی، پوشش به ازای هر فایل و حتی پوشش خطبهخط را نشان خواهد داد. | ||||
| همچنین یک گزارش HTML نیز در دسترس است: | ||||
| 0.0 | ||||
| 3.5 | ||||
| open htmlcov/index.html | ||||
| 168u | ||||
| 168u | ||||
| ساخت مستندات | ||||
| اگر تغییراتی در مستندات ایجاد میکنید، باید قبل از commit کردن آنها، | ||||
| تغییرات خود را ساخته و بازبینی کنید: | ||||
| 0.0 | ||||
| 3.5 | ||||
| invoke docserve | ||||
| 168u | ||||
| 168u | ||||
| برای مرور مستندات، آدرس http://localhost:8000 را در مرورگر خود باز کنید. در حین | ||||
| اجرای وظیفهٔ بالا، هر تغییری که ایجاد کرده و در مستندات ذخیره کنید باید بهطور خودکار | ||||
| در مرورگر نمایش داده شود، زیرا با تشخیص تغییرات در فایلهای منبع مستندات، صفحه را | ||||
| بهصورت زنده بازنشانی (live-reload) میکند. | ||||
| توسعه افزونه | ||||
| برای ساخت یک افزونهٔ جدید Pelican، لطفاً برای دریافت دستورالعملهای تفصیلی به مخزن قالب افزونه https://github.com/getpelican/cookiecutter-pelican-plugin | ||||
| مراجعه کنید. | ||||
| اگر میخواهید در یک افزونهٔ موجود Pelican مشارکت کنید، مراحل | ||||
| بالا را برای راهاندازی Pelican جهت توسعه محلی دنبال کرده و سپس پوشهای برای | ||||
| ذخیره مخازن کلونشدهٔ افزونه ایجاد کنید: | ||||
| 0.0 | ||||
| 3.5 | ||||
| mkdir -p ~/projects/pelican-plugins | ||||
| 168u | ||||
| 168u | ||||
| با این فرض که میخواهید در افزونه Simple Footnotes مشارکت کنید، ابتدا باید در گیتهاب به | ||||
| مخزن Simple Footnotes https://github.com/pelican-plugins/simple-footnotes رفته و دکمهٔ Fork | ||||
| را در بالا سمت راست بزنید. سپس سورس فورک خود را کلون کرده و پروژهٔ | ||||
| بالادست (upstream) را به عنوان ریموت Git اضافه کنید: | ||||
| 0.0 | ||||
| 3.5 | ||||
| git clone https://github.com/YOUR_USERNAME/simple-footnotes.git ~/projects/pelican-plugins/simple-footnotes | ||||
| cd ~/projects/pelican-plugins/simple-footnotes | ||||
| git remote add upstream https://github.com/pelican-plugins/simple-footnotes.git | ||||
| 168u | ||||
| 168u | ||||
| وابستگیهای مورد نیاز را نصب کرده و پروژه را راهاندازی کنید: | ||||
| 0.0 | ||||
| 3.5 | ||||
| invoke setup | ||||
| 168u | ||||
| 168u | ||||
| یک شاخه موضوعی (topic branch) برای رفع باگ یا قابلیت افزونهٔ خود بسازید: | ||||
| 0.0 | ||||
| 3.5 | ||||
| git checkout -b name-of-your-bugfix-or-feature | ||||
| 168u | ||||
| 168u | ||||
| پس از نوشتن آزمونهای جدید برای تغییرات افزونهتان، مجموعه آزمونهای افزونه را اجرا کرده و | ||||
| مطابقت با شیوهنامه نگارش کد را از این طریق بررسی کنید: | ||||
| 0.0 | ||||
| 3.5 | ||||
| invoke tests | ||||
| invoke lint | ||||
| 168u | ||||
| 168u | ||||
| اگر موارد نقض شیوهنامه پیدا شد، بسیاری از آنها را میتوان بهطور خودکار از این طریق برطرف کرد: | ||||
| 0.0 | ||||
| 3.5 | ||||
| invoke format | ||||
| 168u | ||||
| 168u | ||||
| اگر حتی پس از اجرای ابزارهای قالببندی خودکار بالا، موارد نقض شیوهنامه همچنان وجود داشت، | ||||
| باید تغییرات دستی بیشتری ایجاد کنید تا زمانی که invoke lint دیگر | ||||
| هیچ نقض شیوهنامه کدی را گزارش نکند..SS ارسال تغییرات | ||||
| به شرط قبولی در اعتبارسنجی linting و آزمونها، یک فایل RELEASE.md در ریشه | ||||
| پروژه اضافه کنید که شامل نوع انتشار (major، minor، patch) و خلاصهای از | ||||
| تغییرات باشد که به عنوان مدخل سیاهه تغییرات انتشار استفاده خواهد شد. | ||||
| برای مثال: | ||||
| 0.0 | ||||
| 3.5 | ||||
| Release type: patch | ||||
| Fix browser reloading upon changes to content, settings, or theme | ||||
| 168u | ||||
| 168u | ||||
| تغییرات خود را کامیت کرده و شاخه موضوعی خود را push کنید: | ||||
| 0.0 | ||||
| 3.5 | ||||
| git add . | ||||
| git commit -m "Your detailed description of your changes" | ||||
| git push origin name-of-your-bugfix-or-feature | ||||
| 168u | ||||
| 168u | ||||
| در نهایت، به فورک مخزن خود در GitHub رفته و یک pull request ارسال کنید. | ||||
| نکات لاگگیری | ||||
| سعی کنید از لاگگیری با سطوح مناسب استفاده کنید. | ||||
| برای پیامهای لاگی که تکرار نمیشوند، از روش معمول پایتون استفاده کنید: | ||||
| 0.0 | ||||
| 3.5 | ||||
| # at top of file | ||||
| import logging | ||||
| logger = logging.getLogger(__name__) | ||||
| # when needed | ||||
| logger.warning("A warning with %s formatting", arg_to_be_formatted) | ||||
| 168u | ||||
| 168u | ||||
| پیامهای لاگ را خودتان قالببندی نکنید. از قالببندی %s در پیامها استفاده کرده | ||||
| و آرگومانها را به logger ارسال کنید. این موضوع مهم است، زیرا لاگر Pelican | ||||
| برخی آرگومانها، مانند استثناها را پیشپردازش میکند. | ||||
| محدود کردن پیامهای لاگ غیرضروری | ||||
| اگر پیام لاگ ممکن است چندین بار رخ دهد، ممکن است بخواهید لاگ را برای | ||||
| جلوگیری از انباشت بیش از حد پیامها محدود کنید. برای انجام این کار، از آرگومان | ||||
| کلیدواژهای extra برای پیام لاگ با قالب زیر استفاده کنید: | ||||
| 0.0 | ||||
| 3.5 | ||||
| logger.warning("A warning with %s formatting", arg_to_be_formatted, | ||||
| extra={'limit_msg': 'A generic message for too many warnings'}) | ||||
| 168u | ||||
| 168u | ||||
| به صورت اختیاری، اگر پیام عمومی شما نیاز به قالببندی دارد، میتوانید 'limit_args' | ||||
| را نیز به عنوان یک تاپل از آرگومانها در دیکشنری extra تعیین کنید. | ||||
| حد مجاز روی 5 تنظیم شده است، یعنی چهار لاگ اول با همان 'limit_msg' | ||||
| به طور عادی در خروجی نمایش داده میشوند اما پنجمین لاگ با استفاده از 'limit_msg' | ||||
| (و 'limit_args' در صورت وجود) ثبت خواهد شد. پس از پنجمی، پیامهای لاگ | ||||
| مربوطه نادیده گرفته میشوند. | ||||
| به عنوان مثال، اگر میخواهید منابع ناموجود را لاگ کنید، از کد زیر استفاده کنید: | ||||
| 0.0 | ||||
| 3.5 | ||||
| for resource in resources: | ||||
| if resource.is_missing: | ||||
| logger.warning( | ||||
| 'The resource %s is missing', resource.name, | ||||
| extra={'limit_msg': 'Other resources were missing'}) | ||||
| 168u | ||||
| 168u | ||||
| پیامهای لاگ به صورت زیر نمایش داده خواهند شد: | ||||
| 0.0 | ||||
| 3.5 | ||||
| WARNING: The resource prettiest_cat.jpg is missing | ||||
| WARNING: The resource best_cat_ever.jpg is missing | ||||
| WARNING: The resource cutest_cat.jpg is missing | ||||
| WARNING: The resource lolcat.jpg is missing | ||||
| WARNING: Other resources were missing | ||||
| 168u | ||||
| 168u | ||||
| نمایش traceback در لاگها | ||||
| اگر درون یک بلوک except لاگ میگیرید، ممکن است بخواهید اطلاعات | ||||
| traceback را نیز ارائه دهید. میتوانید این کار را با تنظیم آرگومان کلیدواژهای | ||||
| exc_info روی True در هنگام لاگگیری انجام دهید. با این حال، انجام | ||||
| این کار به صورت پیشفرض ممکن است نامطلوب باشد زیرا tracebackها طولانی هستند | ||||
| و میتوانند برای کاربران عادی گیجکننده باشند. سعی کنید آنها را مانند زیر به حالت | ||||
| --debug محدود کنید: | ||||
| 0.0 | ||||
| 3.5 | ||||
| try: | ||||
| some_action() | ||||
| except Exception as e: | ||||
| logger.error('Exception occurred: %s', e, | ||||
| exc_info=settings.get('DEBUG', False)) | ||||
| 168u | ||||
| این بخش نحوه کارکرد درونی Pelican را شرح میدهد. همانطور که خواهید دید، بسیار | ||||
| ساده است، اما کمی مستندات هرگز ضرری ندارد. :) | ||||
| همچنین میتوانید در بخش تاریخچهای درباره Pelican <> گزیدهای از گزارشی را | ||||
| بیابید که نویسنده اصلی همراه با اطلاعاتی در زمینه طراحی نرمافزار نوشته است. | ||||
| ساختار کلی | ||||
| کاری که Pelican انجام میدهد این است که فهرستی از فایلها را دریافت کرده و آنها را | ||||
| به نوعی خروجی پردازش میکند. معمولاً فایلهای ورودی پروندههای reStructuredText و | ||||
| Markdown هستند و خروجی یک وبلاگ است، اما ورودی و خروجی هر دو میتوانند هر آنچه | ||||
| بخواهید باشند. | ||||
| منطق برنامه به کلاسها و مفاهیم متفاوتی تفکیک شده است: | ||||
| 0.0 | ||||
| • 2 | ||||
| Writers مسئول نوشتن فایلها هستند: فایلهای .html، فیدهای RSS و غیره. از | ||||
| آنجا که این عملیات بهطور متداول استفاده میشوند، این شیء یکبار ایجاد شده و | ||||
| سپس به مولدها تحویل داده میشود. | ||||
| • 2 | ||||
| Readers برای خواندن از قالبهای گوناگون استفاده میشوند (در حال حاضر HTML، | ||||
| Markdown و reStructuredText، اما سیستم قابل گسترش است). با دریافت یک فایل، آنها | ||||
| متادیتا (نویسنده، برچسبها، دستهبندی و غیره) و محتوا (با قالببندی HTML) را | ||||
| برمیگردانند. | ||||
| • 2 | ||||
| Generators خروجیهای مختلف را تولید میکنند. برای نمونه، Pelican همراه با | ||||
| ArticlesGenerator و PageGenerator ارائه میشود. با دریافت یک | ||||
| پیکربندی، آنها میتوانند هر کاری را انجام دهند. در اکثر مواقع، کار آنها | ||||
| تولید فایلها از روی ورودیها است. | ||||
| • 2 | ||||
| همچنین Pelican از قالبها (templates) استفاده میکند، بنابراین نوشتن پوسته | ||||
| اختصاصی برایتان آسان خواهد بود. نحو آن Jinja2 https://palletsprojects.com/p/jinja است | ||||
| و یادگیری آن بسیار ساده است، پس در دستبهکار شدن و ساخت پوسته خود درنگ نکنید. | ||||
| 168u | ||||
| چگونه یک Reader جدید پیادهسازی کنیم؟ | ||||
| آیا زبان نشانهگذاری فوقالعادهای وجود دارد که بخواهید به Pelican اضافه کنید؟ | ||||
| خب، تنها کاری که باید انجام دهید ایجاد کلاسی با یک متد read است که محتوای | ||||
| HTML و مقداری متادیتا را برگرداند. | ||||
| نگاهی به خواننده Markdown بیندازید: | ||||
| 0.0 | ||||
| 3.5 | ||||
| from pelican.readers import BaseReader | ||||
| from pelican.utils import pelican_open | ||||
| from markdown import Markdown | ||||
| class MarkdownReader(BaseReader): | ||||
| enabled = True | ||||
| def read(self, source_path): | ||||
| """Parse content and metadata of markdown files""" | ||||
| with pelican_open(source_path) as text: | ||||
| md_extensions = {'markdown.extensions.meta': {}, | ||||
| 'markdown.extensions.codehilite': {}} | ||||
| md = Markdown(extensions=md_extensions.keys(), | ||||
| extension_configs=md_extensions) | ||||
| content = md.convert(text) | ||||
| metadata = {} | ||||
| for name, value in md.Meta.items(): | ||||
| name = name.lower() | ||||
| meta = self.process_metadata(name, value[0]) | ||||
| metadata[name] = meta | ||||
| return content, metadata | ||||
| 168u | ||||
| 168u | ||||
| ساده است، مگر نه؟ | ||||
| اگر خواننده جدید شما به وابستگیهای پایتونی اضافی نیاز دارد، باید دستورهای | ||||
| import مربوط به آنها را در یک بلوک try...except قرار دهید. سپس در داخل | ||||
| کلاس reader، صفت کلاسی enabled را تنظیم کنید تا موفقیت یا عدم موفقیت در | ||||
| واردسازی را نشان دهد. این کار به کاربران امکان میدهد بدون نیاز به نصب ماژولها برای | ||||
| قالبهایی که استفاده نمیکنند، به استفاده از روش نشانهگذاری محبوب خود ادامه دهند. | ||||
| چگونه یک Generator جدید پیادهسازی کنیم؟ | ||||
| مولدها دارای دو متد مهم هستند. شما مجبور نیستید هر دو را ایجاد کنید؛ تنها متدهای | ||||
| موجود فراخوانی خواهند شد. | ||||
| 0.0 | ||||
| • 2 | ||||
| generate_context، که ابتدا برای تمام مولدها فراخوانی میشود. | ||||
| هر کاری را که لازم است انجام دهید و در صورت نیاز زمینه سراسری (global context) | ||||
| را بهروزرسانی کنید. این زمینه بین همه مولدها به اشتراک گذاشته میشود و به قالبها | ||||
| منتقل خواهد شد. برای نمونه، متد generate_context در PageGenerator تمام | ||||
| برگهها را پیدا میکند، آنها را به شیء تبدیل مینماید و زمینه را با آنها پر | ||||
| میکند. دقت کنید که در این مرحله با استفاده از این زمینه هیچ خروجی تولید | ||||
| نکنید، چرا که احتمال دارد با اثر مولدهای دیگر تغییر کند. | ||||
| • 2 | ||||
| سپس generate_output فراخوانی میشود. و حدس میزنید برای چه کاری ساخته شده؟ | ||||
| بله، تولید خروجی. :) اینجاست که ممکن است بخواهید به زمینه نگاه کنید و متدهای شیء | ||||
| writer را که به عنوان آرگومان نخست این تابع ارسال شده است، فراخوانی نمایید. در | ||||
| مثال PageGenerator، این متد تمام برگههای ثبتشده در زمینه سراسری را بررسی | ||||
| کرده و برای هر برگه یافتشده، فایلی را روی دیسک (با استفاده از متد write_file | ||||
| مربوط به writer) خروجی میدهد. | ||||
| 168u | ||||
| تاریخچهای درباره Pelican | ||||
| هشدار: | ||||
| 0.0 | ||||
| 3.5 | ||||
| این صفحه برگرفته از گزارشی است که نویسنده اصلی (Alexis Métaireau) بلافاصله | ||||
| پس از نوشتن Pelican در دسامبر ۲۰۱۰ نوشته است. اطلاعات ممکن است بهروز نباشد. | ||||
| 168u | ||||
| 168u | ||||
| برنامه Pelican یک مولد وبلاگ ایستا و ساده است. این برنامه فایلهای نشانهگذاری | ||||
| (در حال حاضر Markdown یا reStructuredText) را تجزیه کرده و یک پوشه HTML حاوی تمام | ||||
| فایلها درون آن تولید میکند. من پایتون را برای پیادهسازی Pelican انتخاب کردم، | ||||
| چرا که ساده به نظر میرسید و با نیازهای من سازگار بود. نمیخواستم برای هر چیزی یک | ||||
| کلاس تعریف کنم، اما همچنان میخواستم بخشهای برنامهام پیوستگی سست و ناوابستگی | ||||
| (loosely coupled) داشته باشند. در نهایت مشخص شد که این دقیقاً همان چیزی بود که | ||||
| میخواستم. گهگاه به لطف بازخورد برخی کاربران، زمان بسیار کمی از من صرف ارائه اصلاحات | ||||
| روی آن میشد. تاکنون دو بار کد Pelican را بازنویسی و بازسازی کردهام؛ که هر بار | ||||
| کمتر از ۳۰ دقیقه طول کشیده است. | ||||
| موارد کاربرد | ||||
| من پیش از این از WordPress استفاده میکردم؛ راهکاری که میتوانید برای مدیریت | ||||
| وبلاگ خود روی یک سرور وب میزبانی کنید. در اکثر اوقات، ترجیح میدهم برای نوشتن | ||||
| مقالههایم از زبانهای نشانهگذاری مانند Markdown یا reStructuredText استفاده کنم. | ||||
| برای انجام این کار از vim استفاده میکنم. به نظرم مهم است که به افراد اجازه داده | ||||
| شود ابزار مورد نظر خود را برای نوشتن مقالهها انتخاب کنند. از نظر من، یک مدیر وبلاگ | ||||
| تنها باید به شما اجازه دهد هر نوع ورودی را دریافت کرده و آن را به یک وبلاگ تبدیل | ||||
| کنید. این کاری است که Pelican انجام میدهد. شما میتوانید مقالههای خود را با | ||||
| استفاده از ابزار و زبان نشانهگذاری دلخواهتان بنویسید و سپس یک وبلاگ استاتیک HTML | ||||
| تولید کنید. | ||||
| [تصویر] | ||||
| برای انعطافپذیری کافی، Pelican از قالبها پشتیبانی میکند، بنابراین در صورت | ||||
| تمایل میتوانید به راحتی پوستههای دلخواه خود را بنویسید..SS "فرآیند طراحی (Design process)" | ||||
| Pelican بر اساس نیازی که داشتم شکل گرفت. کار را با ایجاد یک برنامهٔ تکفایلی شروع کردم و آن را گسترش دادم تا به قابلیتهای کنونیاش برسد. برای شروع، بخش کوتاهی از مستندات را درباره آنچه میخواستم انجام دهم نوشتم. سپس، محتوایی را که میخواستم تجزیه (parse) کنم (فایلهای reStructuredText) ایجاد کرده و آزمایش با کد را آغاز کردم. Pelican در اولین نسخهٔ قابل استفادهاش ۲۰۰ خط کد داشت و تقریباً شامل ۱۰ تابع و یک کلاس بود. | ||||
| در طول زمان با مشکلات متعددی روبهرو شدم و میخواستم هنگام استفاده از Pelican، ویژگیهایی را به آن اضافه کنم. نخستین تغییری که اعمال کردم، افزودن پشتیبانی از یک فایل تنظیمات بود. ارسال گزینهها از طریق خط فرمان ممکن است، اما در صورت زیاد بودن آنها میتواند خستهکننده باشد. به همین ترتیب، در طول زمان پشتیبانی از موارد گوناگونی را افزودم: فیدهای Atom، چندین پوسته، پشتیبانی از چندین قالب نشانهگذاری و غیره. در مقطعی مشخص شد که ایدهٔ "تنها یک فایل" دیگر برای Pelican مناسب نیست، بنابراین تصمیم گرفتم ساختار آن را بازطراحی کرده و آن را به چندین فایل مختلف تقسیم کنم. | ||||
| من منطق برنامه را به کلاسها و مفاهیم مختلفی تفکیک کردم: | ||||
| 0.0 | ||||
| • 2 | ||||
| writers مسئول تمام فرآیند نوشتن فایلها هستند. آنها مسئول نوشتن فایلهای .html، فیدهای RSS و امثال آن میباشند. از آنجا که این عملیاتها معمولاً بسیار استفاده میشوند، شیء یکبار ایجاد شده و سپس به generatorها ارسال میشود. | ||||
| • 2 | ||||
| readers برای خواندن از قالبهای مختلف استفاده میشوند (در حال حاضر Markdown و reStructuredText، اما سیستم قابل گسترش است). با دادن یک فایل، آنها فراداده (نویسنده، برچسبها، دستهبندی و غیره) و محتوا (با قالببندی HTML) را بازمیگردانند. | ||||
| • 2 | ||||
| generators خروجیهای مختلف را تولید میکنند. به عنوان مثال، Pelican به همراه ArticlesGenerator و PagesGenerator، در میان بقیه موارد، ارائه میشود. بر اساس یک پیکربندی، آنها میتوانند هر آنچه میخواهید انجام دهند. در اکثر مواقع، این فرآیند تولید فایلها از ورودیها (ورودیهای کاربر و فایلها) است. | ||||
| 168u | ||||
| من همچنین با اشیاء محتوا (contents objects) سروکار دارم. آنها میتوانند Articles، Pages، Quotes یا هر چیز دیگری که بخواهید باشند. آنها در ماژول contents.py تعریف شدهاند و نشاندهنده محتوایی هستند که توسط برنامه استفاده میشود. | ||||
| "جزئیات بیشتر (In more detail)" | ||||
| در اینجا نمایی کلی از کلاسهای دخیل در Pelican آورده شده است. | ||||
| [تصویر] | ||||
| رابط (interface) واقعاً وجود ندارد و من آن را صرفاً برای شفافتر شدن تصویر کلی افزودهام. من از duck typing استفاده میکنم و نه رابطها. | ||||
| در درون برنامه، فرآیند زیر دنبال میشود: | ||||
| 0.0 | ||||
| • 2 | ||||
| در ابتدا، خط فرمان تجزیه میشود و بخشی از محتوای کاربر برای مقداردهی اولیهٔ اشیاء generator مختلف به کار میرود. | ||||
| • 2 | ||||
| یک context ایجاد میشود. این بخش شامل تنظیمات حاصل از خط فرمان و در صورت ارائه، یک فایل تنظیمات است. | ||||
| • 2 | ||||
| متد generate_context مربوط به هر generator فراخوانی شده و context را بهروزرسانی میکند. | ||||
| • 2 | ||||
| شیء writer ایجاد شده و به متد generate_output مربوط به هر generator داده میشود. | ||||
| 168u | ||||
| من دو فراخوانی انجام میدهم زیرا مهم است زمانی که خروجی توسط generatorها تولید میشود، context تغییر نکند. به عبارت دیگر، متد نخست یعنی generate_context باید context را تغییر دهد، در حالی که متد دوم یعنی generate_output نباید این کار را انجام دهد. | ||||
| سپس، این بر عهدهٔ generatorها است که در متدهای generate_context و generate_content آنچه را میخواهند انجام دهند. بررسی کلاس ArticlesGenerator به درک برخی مفاهیم دیگر کمک خواهد کرد. آنچه هنگام فراخوانی متد generate_context رخ میدهد به این صورت است: | ||||
| 0.0 | ||||
| • 2 | ||||
| پوشهٔ “path” را خوانده، فایلهای reStructuredText را جستجو میکند، هر یک از آنها را بارگذاری کرده و با آن یک شیء محتوا (Article) میسازد. برای انجام این کار از اشیاء Reader استفاده میشود. | ||||
| • 2 | ||||
| بهروزرسانی context با تمام آن مقالات. | ||||
| 168u | ||||
| سپس، متد generate_content از context و writer برای تولید خروجی مورد نظر استفاده میکند. | ||||
| "تاریخچه انتشار (Release history)" | ||||
| 4.11.0 - 2025-01-15 | ||||
| 0.0 | ||||
| • 2 | ||||
| افزودن تنظیمی برای حذف انتخابی فیلترهای Typogrify (#3439) https://github.com/getpelican/pelican/pull/3439 | ||||
| • 2 | ||||
| افزودن بلوکهای بیشتر به قالب پایه پوستهٔ Simple، که ایجاد پوستههای جدید را از طریق ارثبری از پوستهٔ Simple آسانتر میکند (#3405) https://github.com/getpelican/pelican/pull/3405 | ||||
| • 2 | ||||
| اصلاح رفتار بارگذاری مجدد خودکار (auto-reload) هنگام تغییرات در پوسته، محتوا یا تنظیمات. تنظیم پیشفرض IGNORE_FILES برای نادیده گرفتن بازگشتی تمام فایلهای پنهان و همچنین فیلترهای پیشفرض https://watchfiles.helpmanual.io/api/filters/#watchfiles.DefaultFilter.ignore_dirs از watchfiles.DefaultFilter. (#3441) https://github.com/getpelican/pelican/pull/3441 | ||||
| • 2 | ||||
| دریافت سال جاری از متغیر محیطی SOURCE_DATE_EPOCH در صورت وجود (#3430) https://github.com/getpelican/pelican/pull/3430 | ||||
| • 2 | ||||
| افزودن Python 3.13 به ماتریس آزمون و حذف Python 3.8 (#3435) https://github.com/getpelican/pelican/pull/3435 | ||||
| • 2 | ||||
| الزام به Typogrify 2.1+ و Pygments <2.19 | ||||
| 168u | ||||
| 4.10.2 - 2024-11-27 | ||||
| 0.0 | ||||
| • 2 | ||||
| تغییر مقدار پیشفرض تنظیم IGNORE_FILES برای نادیده گرفتن تمام فایلهای پنهان | ||||
| • 2 | ||||
| رفع مشکل رعایت نشدن SUMMARY_MAX_PARAGRAPHS در برخی ترکیبها با SUMMARY_MAX_LENGTH | ||||
| 168u | ||||
| 4.10.1 - 2024-09-28 | ||||
| 0.0 | ||||
| • 2 | ||||
| رفع خطا هنگام اجرای pelican -r -l | ||||
| • 2 | ||||
| اصلاح مدیریت symlink در pelican-themes | ||||
| 168u | ||||
| 4.10.0 - 2024-09-16 | ||||
| 0.0 | ||||
| • 2 | ||||
| افزودن تنظیمی برای مشخص کردن خلاصه از طریق تعداد پاراگراف | ||||
| • 2 | ||||
| افزودن وضعیتی جدید برای صرفنظر از تولید یک پست | ||||
| • 2 | ||||
| افزودن تنظیمی برای پیوست پارامتر ref به پیوندهای موجود در فیدها | ||||
| • 2 | ||||
| پیکربندی گرداننده گزارشگیری (logging handler) از طریق گزینه خط فرمان --log-handler | ||||
| • 2 | ||||
| حل پیوندهای درونسایتی در خلاصهها | ||||
| • 2 | ||||
| هشدار هنگام پردازش نشدن فایلها به دلیل غیرفعال بودن readerها | ||||
| • 2 | ||||
| افزودن واردکننده پستهای Medium | ||||
| • 2 | ||||
| بهبود گردش کار (workflow) در GitHub Pages | ||||
| • 2 | ||||
| بهبود پوشش آزمون کد | ||||
| • 2 | ||||
| ترجمه مستندات به چینی سادهشده | ||||
| 0.0 | ||||
| • 2 | ||||
| اطمینان از نصب بودن وابستگی tzdata در Windows | ||||
| 168u | ||||
| 4.9.0 - 2023-11-12 | ||||
| 0.0 | ||||
| • 2 | ||||
| ارتقای کدها به نسخه حداقل پشتیبانیشده جدید Python: 3.8 | ||||
| • 2 | ||||
| پشتیبانی از pathlib.Path در تنظیمات (#2758) https://github.com/getpelican/pelican/pull/2758 | ||||
| • 2 | ||||
| بهبودهای گوناگون در پوسته Simple (#2976 https://github.com/getpelican/pelican/pull/2976 و #3234 https://github.com/getpelican/pelican/pull/3234) | ||||
| • 2 | ||||
| استفاده از Furo بهعنوان پوسته مستندات Sphinx (#3023) https://github.com/getpelican/pelican/pull/3023 | ||||
| • 2 | ||||
| تنظیم پیشفرض حداکثر ۱۰۰ مقاله در فیدها (#3127) https://github.com/getpelican/pelican/pull/3127 | ||||
| • 2 | ||||
| افزودن متغیر period_archives common context (#3148) https://github.com/getpelican/pelican/pull/3148 | ||||
| • 2 | ||||
| استفاده از watchfiles بهعنوان زیرسیستم پایش فایل (#3151) https://github.com/getpelican/pelican/pull/3151 | ||||
| • 2 | ||||
| افزودن گردش کار GitHub Actions برای GitHub Pages (#3189) https://github.com/getpelican/pelican/pull/3189 | ||||
| • 2 | ||||
| امکان استفاده از dataclassها در تنظیمات (#3204) https://github.com/getpelican/pelican/pull/3204 | ||||
| • 2 | ||||
| تغییر ابزار ساخت به PDM بهجای Setuptools/Poetry (#3220) https://github.com/getpelican/pelican/pull/3220 | ||||
| • 2 | ||||
| ارائه یک آزمون Jinja به نام plugin_enabled برای پوستهها (#3235) https://github.com/getpelican/pelican/pull/3235 | ||||
| • 2 | ||||
| حفظ ترتیب اتصال در Blinker (#3238) https://github.com/getpelican/pelican/pull/3238 | ||||
| • 2 | ||||
| حذف نمادهای شبکههای اجتماعی از پوسته پیشفرض notmyidea (#3240) https://github.com/getpelican/pelican/pull/3240 | ||||
| • 2 | ||||
| حذف قابلیت غیرقابل اطمینان WRITE_SELECTED (#3243) https://github.com/getpelican/pelican/pull/3243 | ||||
| • 2 | ||||
| واردکننده: گزارش پیوندهای ویدئویی جاسازیشده شکسته هنگام وارد کردن از Tumblr (#3177) https://github.com/getpelican/pelican/issues/3177 | ||||
| • 2 | ||||
| واردکننده: حذف افزودن خط جدید هنگام پیمایش انواع پستهای Photo (#3178) https://github.com/getpelican/pelican/issues/3178 | ||||
| • 2 | ||||
| واردکننده: اجبار تبدیل برچسب زمانی در واردکننده Tumblr به فرمت UTC با آفست (#3221) https://github.com/getpelican/pelican/pull/3221 | ||||
| • 2 | ||||
| واردکننده: استفاده از tempfile برای فایل میانی HTML در Pandoc (#3221) https://github.com/getpelican/pelican/pull/3221 | ||||
| • 2 | ||||
| تغییر لینترها به Ruff (#3223) https://github.com/getpelican/pelican/pull/3223 | ||||
| 168u | ||||
| 4.8.0 - 2022-07-11 | ||||
| 0.0 | ||||
| • 2 | ||||
| استفاده از مقادیر JSON برای تنظیمات اضافی در الگوی وظایف Invoke (#2994) https://github.com/getpelican/pelican/pull/2994 | ||||
| • 2 | ||||
| افزودن برچسب محتوا برای پیوندها، جهت بهبود مواردی مانند کارتهای اجتماعی Twitter (#3001) https://github.com/getpelican/pelican/pull/3001 | ||||
| • 2 | ||||
| بهبود رفتار شمارش کلمات هنگام تولید خلاصه (#3002) https://github.com/getpelican/pelican/pull/3002 | ||||
| 168u | ||||
| 4.7.2 - 2022-02-09 | ||||
| 0.0 | ||||
| • 2 | ||||
| رفع خطای تجزیه نادرست پارامترهای ارائهشده از طریق پرچمهای گزینه -e / --extra-settings (#2938) https://github.com/getpelican/pelican/pull/2938 | ||||
| • 2 | ||||
| افزودن الگوی categories.html به پوسته پیشفرض (#2973) https://github.com/getpelican/pelican/pull/2973 | ||||
| • 2 | ||||
| مستندسازی نحوه استفاده از افزونهها برای تزریق محتوا (#2922) https://github.com/getpelican/pelican/pull/2922 | ||||
| 168u | ||||
| 4.7.1 - 2021-10-12 | ||||
| 0.0 | ||||
| • 2 | ||||
| گسترش ثبت وقایع غنی به مؤلفه سرور (#2927) https://github.com/getpelican/pelican/pull/2927 | ||||
| • 2 | ||||
| رفع مشکلی که در آن فرادادههای نشانهگذاریشده برای دور انداخته شدن، کَش میشدند (#2926) https://github.com/getpelican/pelican/pull/2926 | ||||
| • 2 | ||||
| تنظیم پسوند در سرور جهت امکان تغییر مسیر در صورت نیاز (#2931) https://github.com/getpelican/pelican/pull/2931 | ||||
| • 2 | ||||
| افزودن نوعهای MIME برای فونتهای وب (#2929) https://github.com/getpelican/pelican/pull/2929 | ||||
| • 2 | ||||
| توزیع دادههای نمونه مورد استفاده برای اجرای آزمونها (#2935) https://github.com/getpelican/pelican/pull/2935 | ||||
| • 2 | ||||
| افزودن Python 3.10 به ماتریس آزمایشها | ||||
| 168u | ||||
| 4.7.0 - 2021-10-01 | ||||
| 0.0 | ||||
| • 2 | ||||
| بهبود نمایش پوسته پیشفرض در تلفنهای همراه و دیگر دستگاههای با صفحه نمایش کوچک (#2914) https://github.com/getpelican/pelican/pull/2914 | ||||
| • 2 | ||||
| افزودن پشتیبانی از مقالههای پنهان (#2866) https://github.com/getpelican/pelican/pull/2866 | ||||
| • 2 | ||||
| بهبود رفتار شمارش کلمات هنگام تولید خلاصه برای CJK و دیگر محلیسازیها (#2864) https://github.com/getpelican/pelican/pull/2864 | ||||
| • 2 | ||||
| افزودن نشانگر چرخان پیشرفت حین تولید (#2869) https://github.com/getpelican/pelican/pull/2869 | ||||
| و گزارشگیری غنیتر (#2897) https://github.com/getpelican/pelican/pull/2897، هر دو از طریق Rich https://github.com/willmcgugan/rich | ||||
| • 2 | ||||
| وظایف serve و livereload در Invoke اکنون بهطور خودکار مرورگر وب را باز کرده و وبسایت محلی را نشان میدهند (#2764) https://github.com/getpelican/pelican/pull/2764 | ||||
| • 2 | ||||
| پشتیبانی از برخی کدهای قالب تاریخ مورد استفاده در تاریخهای ISO (#2902) https://github.com/getpelican/pelican/pull/2902 | ||||
| • 2 | ||||
| مستندسازی نحوه افزودن یک writer جدید (#2901) https://github.com/getpelican/pelican/pull/2901 | ||||
| 168u | ||||
| 4.6.0 - 2021-03-23 | ||||
| 0.0 | ||||
| • 2 | ||||
| افزودن الگوی URL جدید به PAGINATION_PATTERNS برای آخرین صفحه در فهرست (#1401) https://github.com/getpelican/pelican/issues/1401 | ||||
| • 2 | ||||
| افزایش سرعت وظیفه livereload در Invoke از طریق کَش کردن (#2847) https://github.com/getpelican/pelican/pull/2847 | ||||
| • 2 | ||||
| نادیده گرفتن مقدار بازگشتی None از سیگنال get_generators (#2850) https://github.com/getpelican/pelican/pull/2850 | ||||
| • 2 | ||||
| تسهیل حداقل نسخه وابستگیها و حذف محدودیتهای بالایی | ||||
| 168u | ||||
| 4.5.4 - 2021-01-04 | ||||
| جایگزینی تعاریف افزونه در تنظیمات با بازنمودهای رشتهای پس از ثبت، تا بهدرستی در حافظه موقت (کَش) ذخیره شوند (#2828) https://github.com/getpelican/pelican/issues/2828. | ||||
| 4.5.3 - 2020-12-01 | ||||
| رفع خطای پیشآمده در PR #2821 | ||||
| 4.5.2 - 2020-11-22 | ||||
| بهبود گزارشگیری از generators و بارگذارهای writer | ||||
| 4.5.1 - 2020-11-02 | ||||
| 0.0 | ||||
| • 2 | ||||
| بازنویسی ساختار کشف پیوندهای درونسایتی بهمنظور تطبیق با انعطاف بیشتر (#2646) https://github.com/getpelican/pelican/issues/2646 | ||||
| • 2 | ||||
| رفع اجرای دوباره افزونهها در حالت بارگذاری خودکار (#2817) https://github.com/getpelican/pelican/issues/2817 | ||||
| • 2 | ||||
| افزودن هشدار برای استفاده از from pelican import signals بهجای import pelican.signals (#2805) https://github.com/getpelican/pelican/issues/2805 | ||||
| 0.0 | ||||
| • 2 | ||||
| افزودن پشتیبانی از افزونههای فضاینام؛ فهرست کردن افزونهها از طریق دستور pelican-plugins | ||||
| • 2 | ||||
| بازنویسی تنظیمات از طریق پرچمهای گزینه خط فرمان -e / --extra-settings | ||||
| • 2 | ||||
| افزودن تنظیمات برای متغیرهای سراسری و آزمونهای سفارشی Jinja | ||||
| • 2 | ||||
| سفارشیسازی علامت تعلیق در خلاصه مقالهها از طریق تنظیم SUMMARY_END_SUFFIX | ||||
| • 2 | ||||
| سفارشیسازی کار با خط تیره در Typogrify با تنظیم جدید TYPOGRIFY_DASHES | ||||
| • 2 | ||||
| پشتیبانی از یونیکد هنگام تولید نامکها (slugs) | ||||
| • 2 | ||||
| پشتیبانی از تولید فایلهای .adoc برای Asciidoc در واردکننده Pelican | ||||
| • 2 | ||||
| بهبود تجربه کاربری هنگام خروج از کارساز وب pelican --listen | ||||
| • 2 | ||||
| بهبود قالب وظایف Invoke | ||||
| • 2 | ||||
| گنجاندن آزمونها در بستههای توزیع کد مبدا | ||||
| • 2 | ||||
| تغییر بستر ادغام مداوم (CI) از Travis به GitHub Actions | ||||
| • 2 | ||||
| حذف پشتیبانی از Python 2.7 | ||||
| 168u | ||||
| 4.2.0 - 2019-10-17 | ||||
| 0.0 | ||||
| • 2 | ||||
| پشتیبانی از SVGهای درونخطی؛ عدم تلقی عنوانهای موجود در SVGها به عنوان عنوانهای HTML | ||||
| • 2 | ||||
| افزودن دستهبندی به فیدها (علاوه بر برچسبها) | ||||
| • 2 | ||||
| بهبود مستندات مربوط به فیلدهای فراداده محتوا | ||||
| • 2 | ||||
| افزودن مستندات برای گنجاندن سایر فایلهای Markdown/reST در محتوا | ||||
| 168u | ||||
| 4.1.3 - 2019-10-09 | ||||
| 0.0 | ||||
| • 2 | ||||
| اصلاح مستندات شروع سریع پیرامون pelican --listen | ||||
| • 2 | ||||
| تنظیم نشانی گوش دادن پیشفرض روی 127.0.0.1 | ||||
| • 2 | ||||
| افزودن وابستگی اضافی/اختیاری Markdown به setup.py | ||||
| • 2 | ||||
| استفاده از نحو صحیح درگاه SSH برای rsync در tasks.py | ||||
| • 2 | ||||
| متمرکز کردن مدیریت تمام تنظیمات منسوخشده در یک بخش | ||||
| • 2 | ||||
| افزودن نشانیهای اینترنتی پروژههای مرتبط برای نمایش در PyPI | ||||
| • 2 | ||||
| نادیده گرفتن برخی از آزمونها در Windows که به دلیل تفاوت در سیستم فایل موفق نمیشدند | ||||
| 168u | ||||
| 4.1.2 - 2019-09-23 | ||||
| اصلاح pelican.settings.load_source جهت جلوگیری از مشکلات حافظه موقت - PR #2621 | ||||
| 4.1.1 - 2019-08-23 | ||||
| 0.0 | ||||
| • 2 | ||||
| افزودن AutoPub برای انتشار خودکار نگارشها هنگام ادغام PR | ||||
| • 2 | ||||
| افزودن کلاسهای CSS برای شکلهای reStructuredText | ||||
| • 2 | ||||
| ارسال argv به نقطه ورود main در Pelican | ||||
| • 2 | ||||
| تنظیم وضعیت پیشفرض محتوا روی یک رشته خالی به جای None | ||||
| 168u | ||||
| 4.1.0 - 2019-07-14 | ||||
| 0.0 | ||||
| • 2 | ||||
| بارگذاری مجدد و زنده مرورگر پس از تغییر فایلها (ارائهشده از طریق وظیفه Invoke) | ||||
| • 2 | ||||
| افزودن pyproject.toml که توسط Poetry مدیریت میشود | ||||
| • 2 | ||||
| پشتیبانی از اجرای python -m pelican | ||||
| • 2 | ||||
| افزودن صفت مسیر نسبی مبدا به محتوا | ||||
| • 2 | ||||
| مجاز بودن دایرکتوریها در EXTRA_PATH_METADATA | ||||
| • 2 | ||||
| افزودن متغیر all_articles به صفحههای دورهای (برای قابلیت پستهای اخیر) | ||||
| • 2 | ||||
| بهبود خروجی حالت اشکالزدایی (debug) | ||||
| • 2 | ||||
| حذف خلاصههای خالی یا تکراری از فید Atom | ||||
| • 2 | ||||
| رفع اشکالات در صفحهبندی، pelican-import، pelican-quickstart و واردکننده فید | ||||
| 168u | ||||
| 4.0.1 (2018-11-30) | ||||
| 0.0 | ||||
| • 2 | ||||
| بازسازی ساختار ثبت وقایع در pelican.server | ||||
| • 2 | ||||
| رفع اشکالی که در آن تمام فایلهای ایستا به عنوان "draft" پردازش میشدند | ||||
| • 2 | ||||
| رفع اشکال در خودکارسازی Invoke/Makefile، واردکننده و سایر موارد متفرقه | ||||
| 168u | ||||
| در صورت ارتقا از 3.7.x یا قبلتر، لطفاً توجه داشته باشید که تنظیمات مربوط به نامک در | ||||
| 4.0+ به جای %s از {slug} و/یا {lang} استفاده میکنند. اگر با تنظیماتی به سبک | ||||
| %s مواجه شود، Pelican هشداری نمایش میدهد و به تنظیمات پیشفرض | ||||
| بازمیگردد. ممکن است برخی پوستههای ارائهشده توسط کاربران تلاش کنند مقادیر تنظیمات را قالببندی | ||||
| کنند اما هنگام ساخت سایت با خطای TypeError مواجه شوند. در چنین مواردی، پوسته باید | ||||
| بهروزرسانی شود. برای مثال، به جای TAG_FEED_ATOM|format(tag.slug)، از | ||||
| TAG_FEED_ATOM.format(slug=tag.slug) استفاده کنید. | ||||
| 4.0.0 (2018-11-13) | ||||
| 0.0 | ||||
| • 2 | ||||
| جایگزینی اسکریپت develop_server.sh با pelican --listen | ||||
| • 2 | ||||
| بهبود رفتار کپی/پیوند برای فایلهای ایستای حجیم (مانند ویدیوها) | ||||
| • 2 | ||||
| نحو جدید {static} برای پیوند به محتوای ایستا؛ محتوایی که توسط | ||||
| {static} و {attach} پیوند داده شده باشد، بهطور خودکار کپی میشود حتی اگر در | ||||
| STATIC_PATHS نباشد | ||||
| • 2 | ||||
| صفحهها اکنون میتوانند دارای وضعیت draft باشند | ||||
| • 2 | ||||
| نمایش تنظیمات جاری با استفاده از پرچم جدید --print-settings | ||||
| • 2 | ||||
| تمام تنظیمات مربوط به نامکها اکنون به جای %s از {slug} و/یا {lang} استفاده میکنند. | ||||
| اگر با تنظیماتی به سبک %s مواجه شود، Pelican هشداری نمایش داده و | ||||
| به تنظیمات پیشفرض بازمیگردد. | ||||
| • 2 | ||||
| سیگنالهای جدید: feed_generated و page_generated_write_page | ||||
| • 2 | ||||
| جایگزینی Fabric با Invoke و قالب fabfile.py با tasks.py | ||||
| • 2 | ||||
| جایگزینی PAGINATED_DIRECT_TEMPLATES با PAGINATED_TEMPLATES، گسترش | ||||
| کنترل صفحهبندی به همه قالبها و متغیر ساختن اندازه صفحه | ||||
| • 2 | ||||
| جایگزینی SLUG_SUBSTITUTIONS (و موارد مرتبط) با SLUG_REGEX_SUBSTITUTIONS | ||||
| برای کنترل دقیقتر | ||||
| • 2 | ||||
| مقدار '{base_name}' در تنظیم PAGINATION_PATTERNS دیگر عبارت | ||||
| 'bar' را از 'foo/bar.html' حذف نمیکند (مگر اینکه 'bar' == 'index' باشد). | ||||
| • 2 | ||||
| تنظیمات ARTICLE_ORDER_BY و PAGE_ORDER_BY اکنون بر ۱) صفحههای دستهبندی، برچسب | ||||
| و نویسنده ۲) فیدها ۳) مقالهها و صفحههای پیشنویس و پنهان نیز اثر میگذارند | ||||
| • 2 | ||||
| تنظیمات جدید ARTICLE_TRANSLATION_ID و PAGE_TRANSLATION_ID برای | ||||
| مشخص کردن ویژگیهای فراداده بهکاررفته در شناسایی/غیرفعالسازی ترجمهها | ||||
| • 2 | ||||
| امکان تجزیه چند مورد تکرار برچسبهای فراداده به صورت یک فهرست در خواننده HTML | ||||
| • 2 | ||||
| واردکننده جدید نسخه پشتیبان XML در Blogger | ||||
| • 2 | ||||
| واردکننده Wordpress اکنون در صورتی که فایلها با --wp-attach بارگیری شده باشند، | ||||
| پیوندهای فایل را بهروزرسانی میکند تا به نسخههای محلی اشاره کنند. | ||||
| • 2 | ||||
| واردکننده دیگر خطهای جدید اضافی اضافه نمیکند، تا از شکستهشدن مشخصههای HTML | ||||
| جلوگیری شود. | ||||
| • 2 | ||||
| کارساز Pelican اکنون هنگام حلوفصل foo، فایلهای foo.html و foo/index.html را | ||||
| بر foo/ اولویت میدهد. | ||||
| 0.0 | ||||
| • 2 | ||||
| رفع مشکلات مربوط به locale در اسکریپت Quickstart | ||||
| • 2 | ||||
| مشخص کردن کدگذاری برای README و CHANGELOG در setup.py | ||||
| 168u | ||||
| 3.7.0 (2016-12-12) | ||||
| 0.0 | ||||
| • 2 | ||||
| فیدهای Atom علاوه بر <summary>، تگ <content> را نیز در خروجی میآورند | ||||
| • 2 | ||||
| فیدهای Atom از <published> برای تاریخ انتشار اولیه و از <updated> برای ویرایشها استفاده میکنند | ||||
| • 2 | ||||
| سادهسازی تولید شناسه فید Atom و پشتیبانی از قطعههای نشانی وب (URL fragments) | ||||
| • 2 | ||||
| تولید فیدهای دستهبندی با عنوانهای مختص هر دسته | ||||
| • 2 | ||||
| فیدهای RSS اکنون بهطور پیشفرض به جای کل محتوا، خلاصه را ارائه میدهند؛ | ||||
| برای بازگشت به رفتار پیشین، RSS_FEED_SUMMARY_ONLY = False را تنظیم کنید | ||||
| • 2 | ||||
| جایگزینی تنظیم MD_EXTENSIONS با MARKDOWN | ||||
| • 2 | ||||
| جایگزینی JINJA_EXTENSIONS با تنظیم پایدارتر JINJA_ENVIRONMENT | ||||
| • 2 | ||||
| بهبود منطق کوتاهسازی خلاصه برای مدیریت نویسههای خاص و تگهای چندخطی، با استفاده از تجزیهکننده HTML به جای عبارتهای باقاعده | ||||
| • 2 | ||||
| لحاظ کردن خلاصه هنگام جستجو برای جایگزینی پیوندهای درونسایتی | ||||
| • 2 | ||||
| پیوند دادن به نویسندگان و نمایه از طریق نحو {author}name و {index} | ||||
| • 2 | ||||
| بازنویسی نام ابزارکها از طریق LINKS_WIDGET_NAME و SOCIAL_WIDGET_NAME | ||||
| • 2 | ||||
| افزودن گزینه INDEX_SAVE_AS برای لغو مقدار پیشفرض index.html | ||||
| • 2 | ||||
| حذف متغیر زمینه PAGES برای قالبها به نفع pages | ||||
| • 2 | ||||
| گزینه SLUG_SUBSTITUTIONS اکنون عناصر سهتایی را میپذیرد که به نامکهای نشانی وب اجازه میدهد حاوی نویسههای غیرحرفی-عددی باشند | ||||
| • 2 | ||||
| امکان کنترل نامکهای برچسب و دستهبندی با دقت بیشتر با استفاده از تنظیمات TAG_SUBSTITUTIONS و CATEGORY_SUBSTITUTIONS | ||||
| • 2 | ||||
| امکان کنترل نامکهای نویسنده با دقت بیشتر با استفاده از تنظیم AUTHOR_SUBSTITUTIONS | ||||
| • 2 | ||||
| امکان تعریف DEFAULT_DATE به صورت رشته | ||||
| • 2 | ||||
| استفاده از mtime به جای ctime هنگامی که DEFAULT_DATE = 'fs' باشد | ||||
| • 2 | ||||
| افزودن گزینه --fatal=errors|warnings برای استفاده در یکپارچهسازی مداوم (CI) | ||||
| • 2 | ||||
| هنگام استفاده از حافظه موقت در سطح تولیدکننده، اطمینان حاصل میشود که فایلهای ذخیرهشده پیشین به جای فقط فایلهای جدید پردازش شوند. | ||||
| • 2 | ||||
| افزودن اطلاعات نسخه Python و Pelican به خروجی اشکالزدایی | ||||
| • 2 | ||||
| بهبود سازگاری با Python 3.5 | ||||
| • 2 | ||||
| انطباق با رهنمودهای PEP8 و اعمال آنها | ||||
| • 2 | ||||
| جایگزینی جداول در مستندات تنظیمات با دستورالعملهای data:: | ||||
| 168u | ||||
| 3.6.3 (2015-08-14) | ||||
| 0.0 | ||||
| • 2 | ||||
| رفع مشکل مجوزهای دسترسی در تاربال نسخه منتشرشده | ||||
| 168u | ||||
| 3.6.2 (2015-08-01) | ||||
| 0.0 | ||||
| • 2 | ||||
| رفع خطاهای نصب مرتبط با یونیکد در آزمونها | ||||
| • 2 | ||||
| عدم نمایش صفحهبندی در قالب notmyidea در صورتی که فقط یک صفحه وجود دارد | ||||
| • 2 | ||||
| در دسترس قرار دادن صفحات پنهان در زمینه (context) | ||||
| • 2 | ||||
| بهبود مقایسه URLWrapper | ||||
| 168u | ||||
| 3.6.0 (2015-06-15) | ||||
| 0.0 | ||||
| • 2 | ||||
| غیرفعالسازی پیشفرض حافظه موقت برای جلوگیری از سردرگمیهای احتمالی | ||||
| • 2 | ||||
| بهبود رفتار حافظه موقت و جایگزینی pickle با cpickle | ||||
| • 2 | ||||
| امکان استفاده از محتوای Markdown یا reST در فیلدهای فراداده به جز summary | ||||
| • 2 | ||||
| پشتیبانی از فهرستهای نویسنده/برچسب جداشده با نقطهویرگول | ||||
| • 2 | ||||
| بهبود انعطافپذیری در مرتبسازی مقالهها | ||||
| • 2 | ||||
| افزودن آرگومان --relative-urls | ||||
| • 2 | ||||
| پشتیبانی از شنود سرور توسعه (devserver) روی نشانیهایی به جز localhost | ||||
| • 2 | ||||
| یکپارچهسازی گردانندههای سرور HTTP در سرتاسر برنامه به pelican.server | ||||
| • 2 | ||||
| مدیریت پیوندهای درونسایتی به پستهای پیشنویس | ||||
| • 2 | ||||
| انتقال tag_cloud از هسته به افزونه | ||||
| • 2 | ||||
| بارگذاری منابع خارجی در قالب پیشفرض از طریق HTTPS | ||||
| • 2 | ||||
| درونریزی پیشنویسها از فایل XML وردپرس | ||||
| • 2 | ||||
| بهبود پشتیبانی برای کاربران ویندوز | ||||
| • 2 | ||||
| ارتقای ثبت وقایع و مجموعه آزمونها | ||||
| • 2 | ||||
| پاکسازی و بازسازی ساختار کدها | ||||
| • 2 | ||||
| سیگنالهای جدید: all_generators_finalized و page_writer_finalized | ||||
| 168u | ||||
| 3.5.0 (2014-11-04) | ||||
| 0.0 | ||||
| • 2 | ||||
| معرفی تنظیمات ARTICLE_ORDER_BY و PAGE_ORDER_BY برای کنترل ترتیب مقالهها و صفحات. | ||||
| • 2 | ||||
| گنجاندن اطلاعات منطقه زمانی در تاریخهای نمایشیافته در قالبها. | ||||
| • 2 | ||||
| نمایان ساختن نام خواننده (reader) در فرادادههای مقالهها و صفحات. | ||||
| • 2 | ||||
| افزودن قابلیت ذخیرهسازی فایلهای ایستا در کنار محتوا در همان دایرکتوری مقالهها و صفحات با استفاده از {attach} در مسیر. | ||||
| • 2 | ||||
| جلوگیری از ایجاد استثنا در Pelican هنگام وجود فرادادههای تکراری در یک فایل Markdown. | ||||
| • 2 | ||||
| معرفی تنظیم TYPOGRIFY_IGNORE_TAGS جهت افزودن تگهای HTML که باید توسط Typogrify نادیده گرفته شوند. | ||||
| • 2 | ||||
| افزودن قابلیت استفاده از - در قالبهای تاریخ برای حذف صفرهای ابتدایی. برای مثال، %-d/%-m/%y اکنون منجر به تاریخ 9/8/12 خواهد شد. | ||||
| • 2 | ||||
| اطمینان از غیرفعالسازی صحیح تولید فید در جریان پیکربندی راهاندازی سریع (quickstart). | ||||
| • 2 | ||||
| رفع مشکل تطابق نادرست دایرکتوریهای فرعی در PAGE_EXCLUDES و ARTICLE_EXCLUDES. | ||||
| • 2 | ||||
| معرفی تنظیم STATIC_EXCLUDE برای افزودن استثناهای فایلهای ایستا. | ||||
| • 2 | ||||
| رفع اشکال هنگام استفاده از PAGINATION_PATTERNS در زمانی که RELATIVE_URLS فعال است. | ||||
| • 2 | ||||
| رفع مشکلی در تولید فید که باعث میشد پیوندها هنگام استفاده از سایر localeها از زبان نادرستی برای نام ماهها استفاده کنند. | ||||
| • 2 | ||||
| رفع مشکلی که در آن فهرست نویسندگان در قالب ساده بهدرستی قالببندی نمیشد. | ||||
| • 2 | ||||
| رفع مشکلی در هنگام تجزیه نشانیهای وب غیررشتهای از تنظیمات. | ||||
| • 2 | ||||
| بهبود یکدستی پیامهای اشکالزدایی و هشدار. | ||||
| 0.0 | ||||
| • 2 | ||||
| افزایش سرعت تولید محتوا از طریق سازوکار جدید کشگذاری (caching) | ||||
| • 2 | ||||
| افزودن امکان تولید انتخابی پستها (به جای ساخت همیشگی کل سایت) | ||||
| • 2 | ||||
| بهبودهای متعدد در مستندات، از جمله تغییر به پوستهٔ زیباتر RtD | ||||
| • 2 | ||||
| افزودن پشتیبانی از چندین مسیر محتوا و افزونه | ||||
| • 2 | ||||
| افزودن فیلد فرادادهٔ :modified: به عنوان مکمل :date:. | ||||
| برای مشخصکردن آخرین تاریخ و زمان بهروزرسانی مقاله بهطور مستقل از تاریخ و زمان انتشار آن به کار میرود. | ||||
| • 2 | ||||
| افزودن پشتیبانی از چندین نویسنده از طریق فیلد فرادادهٔ جدید :authors: | ||||
| • 2 | ||||
| پایش تغییرات در دایرکتوریهای ایستا در حالت بازتولید خودکار | ||||
| • 2 | ||||
| افزودن پالایهها برای محدود کردن خروجی ثبت وقایع در صورت تمایل | ||||
| • 2 | ||||
| افزودن پشتیبانی از زبان به پیشنویسها | ||||
| • 2 | ||||
| افزودن تنظیم SLUGIFY_SOURCE برای کنترل چگونگی ایجاد نامکهای (slugs) پستها | ||||
| • 2 | ||||
| رفع مشکلات متعدد مربوط به محلیسازی (locale) و کدگذاری | ||||
| • 2 | ||||
| اِعمال فیلتر Typogrify بر خلاصهٔ پستها | ||||
| • 2 | ||||
| حفظ فرادادههای فایل (مانند برچسبهای زمانی) هنگام رونوشت فایلهای ایستا در خروجی | ||||
| • 2 | ||||
| انتقال پشتیبانی از AsciiDoc از هستهٔ Pelican به یک افزونهٔ جداگانه | ||||
| • 2 | ||||
| تولید پیوندهای درونخطی به جای پیوندهای ارجاعی در هنگام وارد کردن محتوا | ||||
| • 2 | ||||
| بهبود رفتار کار با تنظیم IGNORE_FILES | ||||
| • 2 | ||||
| گریز (escape) صحیح نویسههای نمادین در نام برچسبها (مانند C++) | ||||
| • 2 | ||||
| تغییرات جزئی برای سازگاری با Python 3.4 | ||||
| • 2 | ||||
| افزودن چندین سیگنال جدید | ||||
| 168u | ||||
| 3.3.0 (2013-09-24) | ||||
| 0.0 | ||||
| • 2 | ||||
| حذف پشتیبانی از Python 3.2 به نفع Python 3.3 | ||||
| • 2 | ||||
| افزودن Fabfile جهت امکان استفاده از Fabric به جای Make برای خودکارسازی گردش کار | ||||
| • 2 | ||||
| تنظیم OUTPUT_RETENTION میتواند برای جلوگیری از حذف فرادادهها (مانند دادههای VCS نظیر .hg و .git) از دایرکتوری خروجی به کار رود | ||||
| • 2 | ||||
| واردسازی محتوا از Tumblr | ||||
| • 2 | ||||
| بهبود منطق و یکدستی هنگام پاکسازی پوشهٔ خروجی | ||||
| • 2 | ||||
| بهبود نسخهبندی مستندات و خودکارسازی انتشار | ||||
| • 2 | ||||
| بهبود انعطافپذیری صفحهبندی | ||||
| • 2 | ||||
| تغییر نام سیگنالها برای یکدستی بیشتر (ممکن است برخی افزونهها نیازمند بهروزرسانی باشند) | ||||
| • 2 | ||||
| انتقال استخراج فراداده از مولدها (generators) به خوانندهها (readers)؛ استخراج فراداده دیگر مختص مقالهها نیست | ||||
| • 2 | ||||
| منسوخ شدن FILES_TO_COPY به نفع STATIC_PATHS و EXTRA_PATH_METADATA | ||||
| • 2 | ||||
| خلاصهها در پستهای Markdown دیگر شامل پانویسها نمیشوند | ||||
| • 2 | ||||
| حذف فاصلههای سفید غیرضروری در خروجی از طریق پارامتر lstrip_blocks در Jinja | ||||
| • 2 | ||||
| انتقال تولید PDF از هسته به افزونه | ||||
| • 2 | ||||
| جایگزینی تنظیم MARKUP با READERS | ||||
| • 2 | ||||
| افزودن هشدار در صورت عدم وجود ویژگی alt در برچسب img | ||||
| • 2 | ||||
| افزودن پشتیبانی از {} در نحو پیوندهای نسبی، علاوه بر || | ||||
| • 2 | ||||
| افزودن پشتیبانی از پیوندهای نسبی {tag} و {category} | ||||
| • 2 | ||||
| افزودن سیگنال content_written | ||||
| 168u | ||||
| "3.2.1 و 3.2.2" | ||||
| 0.0 | ||||
| • 2 | ||||
| تسهیل گنجاندن در مجموعه پورتهای FreeBSD (Ports Collection) | ||||
| 168u | ||||
| 3.2 (2013-04-24) | ||||
| 0.0 | ||||
| • 2 | ||||
| پشتیبانی از Python 3! | ||||
| • 2 | ||||
| امکان تغییر مسیر ذخیرهسازی صفحه از طریق فراداده (برای نمونه امکان استفاده از یک صفحهٔ ایستا به عنوان صفحهٔ اصلی سایت) | ||||
| • 2 | ||||
| بایگانیهای دورهای زمانی (بایگانی سالانه، ماهانه و روزانهٔ پستها) | ||||
| • 2 | ||||
| واردسازی وبلاگ از Posterous | ||||
| • 2 | ||||
| بهبود واردسازی وبلاگ از WordPress | ||||
| • 2 | ||||
| انتقال افزونهها به مخزن جداگانه | ||||
| • 2 | ||||
| بهبود تجزیهکنندهٔ HTML | ||||
| • 2 | ||||
| فراهم شدن قابلیت نمایش یا پنهانسازی دستهها در منو با استفاده از گزینهٔ DISPLAY_CATEGORIES_ON_MENU | ||||
| • 2 | ||||
| امکان چشمپوشی از فایلها در بازتولید خودکار با استفاده از تنظیم IGNORE_FILES | ||||
| • 2 | ||||
| بهبود بازخورد پس از تولید به کاربر | ||||
| • 2 | ||||
| برای پستهای چندزبانه، استفاده از فراداده جهت تعیین مورد اصلی و ترجمهشده | ||||
| • 2 | ||||
| افزودن .mdown به فهرست پسوندهای فایل Markdown پشتیبانیشده | ||||
| • 2 | ||||
| تولید نشانیهای وب نسبی نسبت به سند (RELATIVE_URLS) اکنون بهطور پیشفرض غیرفعال است | ||||
| 0.0 | ||||
| • 2 | ||||
| واردکننده اکنون بهطور پیشفرض اسلاگها را در فایلها ذخیره میکند. این ویژگی میتواند با گزینهٔ --disable-slugs غیرفعال شود. | ||||
| • 2 | ||||
| بهبود مدیریت پیوندها به منابع درونسایتی | ||||
| • 2 | ||||
| اطمینان از اینکه واردکردن از WordPress برای همه انواع پایان خطها در محتوای پست، بندها (پاراگرافها) را اضافه میکند | ||||
| • 2 | ||||
| رمزگشایی موجودیتهای HTML در عناوین پستهای WordPress هنگام وارد کردن | ||||
| • 2 | ||||
| بهبود ظاهر آیکون LinkedIn در پوسته پیشفرض | ||||
| • 2 | ||||
| افزودن پشتیبانی از آیکونهای شبکههای اجتماعی GitHub و +Google در پوسته پیشفرض | ||||
| • 2 | ||||
| بهینهسازی آیکونهای شبکههای اجتماعی | ||||
| • 2 | ||||
| افزودن FEED_ALL_ATOM و FEED_ALL_RSS برای تولید خوراکهای شامل همه پستها صرفنظر از زبان آنها | ||||
| • 2 | ||||
| تقسیم TRANSLATION_FEED به TRANSLATION_FEED_ATOM و TRANSLATION_FEED_RSS | ||||
| • 2 | ||||
| اکنون میتوان خوراکهای مختلف را بهصورت جداگانه فعال یا غیرفعال کرد | ||||
| • 2 | ||||
| امکان خالی بودن نویسنده: اگر تنظیم AUTHOR مشخص نشده باشد، نویسنده دیگر بهطور پیشفرض به ${USER} تنظیم نمیشود و چنانچه نویسندهٔ پست خالی باشد، پست حاوی هیچ اطلاعاتی از نویسنده نخواهد بود | ||||
| • 2 | ||||
| انتقال پشتیبانی از LESS و Webassets از هسته Pelican به افزونه | ||||
| • 2 | ||||
| تنظیم DEFAULT_DATE اکنون بهطور پیشفرض به None مقداردهی میشود، به این معنی که مقالهها تولید نخواهند شد مگر اینکه متاداده تاریخ مشخص شده باشد | ||||
| • 2 | ||||
| افزودن تنظیم FILENAME_METADATA برای پشتیبانی از استخراج متاداده از نام فایل | ||||
| • 2 | ||||
| افزودن افزونهٔ gzip_cache برای فشردهسازی فایلهای متنی رایج در یک فایل .gz درون همان دایرکتوری فایل اصلی، که از فشردهسازی فایلها توسط کارساز (مانند Nginx) در حین فراخوانی HTTP جلوگیری میکند | ||||
| • 2 | ||||
| افزودن پشتیبانی از محتوای دارای قالببندی AsciiDoc | ||||
| • 2 | ||||
| افزودن تنظیم USE_FOLDER_AS_CATEGORY برای فعال یا غیرفعال کردن این ویژگی | ||||
| • 2 | ||||
| پشتیبانی از فایلهای قالب دلخواه Jinja | ||||
| • 2 | ||||
| بازیابی آزمونهای کارکردی پایهای | ||||
| • 2 | ||||
| سیگنالهای جدید: generator_init، get_generators و article_generate_preread | ||||
| 168u | ||||
| 3.0 (2012-08-08) | ||||
| 0.0 | ||||
| • 2 | ||||
| بازطراحی روش مدیریت نشانیهای وب (URLها) | ||||
| • 2 | ||||
| بهبود مستندات انگلیسی | ||||
| • 2 | ||||
| رفع ایراد بستهبندی با استفاده از entrypointهای setuptools | ||||
| • 2 | ||||
| افزودن پشتیبانی از typogrify | ||||
| • 2 | ||||
| افزودن روشی برای غیرفعال کردن تولید خوراک | ||||
| • 2 | ||||
| افزودن پشتیبانی از DIRECT_TEMPLATES | ||||
| • 2 | ||||
| مجاز شمردن چندین پسوند برای فایلهای محتوا | ||||
| • 2 | ||||
| افزودن پشتیبانی از LESS | ||||
| • 2 | ||||
| بهبود اسکریپت وارد کردن | ||||
| • 2 | ||||
| افزودن آزمونهای کارکردی | ||||
| • 2 | ||||
| پشتیبانی از Rsync در Makefile تولیدشده | ||||
| • 2 | ||||
| بهبود پشتیبانی از خوراک (برای مثال، اتصال آسان به Feedburner) | ||||
| • 2 | ||||
| افزودن پشتیبانی از abbr در reST | ||||
| • 2 | ||||
| رفع چندین باگ :-) | ||||
| 168u | ||||
| 2.8 (2012-02-28) | ||||
| 0.0 | ||||
| • 2 | ||||
| واردکننده Dotclear | ||||
| • 2 | ||||
| امکان استفاده از افزونههای Markdown | ||||
| • 2 | ||||
| پوستهها اکنون بهراحتی قابل توسعه هستند | ||||
| • 2 | ||||
| عدم نمایش اطلاعات صفحهبندی در صورتی که فقط یک صفحه وجود دارد | ||||
| • 2 | ||||
| افزودن یک صفحه به ازای هر نویسنده، شامل تمام مقالههای آنها | ||||
| • 2 | ||||
| بهبود مجموعه آزمونها | ||||
| • 2 | ||||
| سادهتر شدن توسعهٔ پوستهها | ||||
| • 2 | ||||
| حذف پشتیبانی از Skribit | ||||
| • 2 | ||||
| افزودن اسکریپت pelican-quickstart | ||||
| • 2 | ||||
| رفع مشکلات مربوط به منطقه زمانی | ||||
| • 2 | ||||
| افزودن چند اسکریپت برای پشتیبانی از Windows | ||||
| • 2 | ||||
| امکان مشخص کردن تاریخ بر حسب ثانیه | ||||
| • 2 | ||||
| عدم شکست در هنگام تولید پستها (رد کردن و ادامه دادن) | ||||
| • 2 | ||||
| امکان استفاده از تاریخهای آینده | ||||
| • 2 | ||||
| پشتیبانی از مناطق زمانی مختلف برای هر زبان | ||||
| • 2 | ||||
| بهبود مستندات | ||||
| 0.0 | ||||
| • 2 | ||||
| استفاده از logging بهجای ارسال خروجی با چاپ در stdout | ||||
| • 2 | ||||
| پشتیبانی از فیلترهای سفارشی Jinja | ||||
| • 2 | ||||
| سازگاری با Python 2.5 | ||||
| • 2 | ||||
| افزودن مدیریت پوسته | ||||
| • 2 | ||||
| بستهبندی برای Debian | ||||
| • 2 | ||||
| افزودن پشتیبانی از پیشنویس | ||||
| 168u | ||||
| 2.6 (2011-03-08) | ||||
| 0.0 | ||||
| • 2 | ||||
| تغییرات در ساختار دایرکتوری خروجی | ||||
| • 2 | ||||
| آسانتر شدن کار با قالبها و ساخت آنها | ||||
| • 2 | ||||
| افزودن پشتیبانی از RSS (پیشتر فقط شامل Atom میشد) | ||||
| • 2 | ||||
| افزودن پشتیبانی از برچسبها در فیدها | ||||
| • 2 | ||||
| بهبود مستندات | ||||
| • 2 | ||||
| افزودن یک پوسته دیگر (brownstone) | ||||
| • 2 | ||||
| افزودن ترجمهها | ||||
| • 2 | ||||
| افزودن راهکاری برای استفاده از نشانیهای (URL) تمیزتر بهکمک ماژول بازنویسی نشانی (یا معادل آن) | ||||
| • 2 | ||||
| افزودن ابر برچسبها | ||||
| • 2 | ||||
| افزودن قابلیت بارگذاری مجدد خودکار: با هر بار تشخیص تغییر، وبلاگ بهطور خودکار دوباره تولید میشود | ||||
| • 2 | ||||
| ترجمه مستندات به فرانسوی | ||||
| • 2 | ||||
| وارد کردن وبلاگ از یک فید RSS | ||||
| • 2 | ||||
| پشتیبانی از صفحهبندی | ||||
| • 2 | ||||
| افزودن پشتیبانی از Skribit | ||||
| 168u | ||||
| 2.5 (2010-11-20) | ||||
| 0.0 | ||||
| • 2 | ||||
| وارد کردن از WordPress | ||||
| • 2 | ||||
| افزودن چندین پوسته جدید (martyalchin / wide-notmyidea) | ||||
| • 2 | ||||
| نخستین گزارش باگ! | ||||
| • 2 | ||||
| پشتیبانی از Linkedin | ||||
| • 2 | ||||
| افزودن بخش پرسشهای متداول (FAQ) | ||||
| • 2 | ||||
| پشتیبانی از Google Analytics | ||||
| • 2 | ||||
| پشتیبانی از Twitter | ||||
| • 2 | ||||
| استفاده از URLهای نسبی، نه ایستا | ||||
| 168u | ||||
| 2.4 (2010-11-06) | ||||
| 0.0 | ||||
| • 2 | ||||
| تغییرات جزئی در پوستهها | ||||
| • 2 | ||||
| افزودن پشتیبانی از Disqus (جهت ثبت نظرات) | ||||
| • 2 | ||||
| بازآرایی مجدد کد | ||||
| • 2 | ||||
| افزودن تنظیمات پیکربندی مربوط به صفحهها | ||||
| • 2 | ||||
| امکان تولید ورودیهای وبلاگ در قالب PDF | ||||
| 168u | ||||
| 2.3 (2010-10-31) | ||||
| 0.0 | ||||
| • 2 | ||||
| پشتیبانی از Markdown | ||||
| 168u | ||||
| 2.2 (2010-10-30) | ||||
| 0.0 | ||||
| • 2 | ||||
| زیباسازی خروجی | ||||
| • 2 | ||||
| پشتیبانی و مدیریت صفحههای ایستا | ||||
| 168u | ||||
| 2.1 (2010-10-30) | ||||
| 0.0 | ||||
| • 2 | ||||
| انتخاب notmyidea بهعنوان پوسته پیشفرض | ||||
| 168u | ||||
| 2.0 (2010-10-30) | ||||
| 0.0 | ||||
| • 2 | ||||
| بازآرایی کد برای توسعهپذیری بیشتر | ||||
| • 2 | ||||
| تغییر در متغیرهای تنظیمات | ||||
| 168u | ||||
| 1.2 (2010-09-28) | ||||
| 0.0 | ||||
| • 2 | ||||
| افزودن گزینه اشکالزدایی (debug) | ||||
| • 2 | ||||
| افزودن فیدها به تفکیک دستهبندی | ||||
| • 2 | ||||
| استفاده از سیستمفایل جهت دریافت تاریخها در صورت عدم ارائه فراداده | ||||
| • 2 | ||||
| افزودن پشتیبانی از Pygments | ||||
| 168u | ||||
| 1.1 (2010-08-19) | ||||
| 0.0 | ||||
| • 2 | ||||
| نخستین نسخه کارآمد | ||||
| 168u | ||||
| "نویسنده (AUTHOR)" | ||||
| Justin Mayer.SH "کپیرایت و تکثیر (COPYRIGHT)" | ||||
| 2010–2025 |
| December 25, 2025 | 4 |