چند وقت پیش و بعد از برخورد به یک مشکل خاص و تلاش برای حل اون مطلبی نوشتم به نام " How much should we extend Web Applications? ". مشکل من این بود که می خواستم هنگام به روز شدن وبلاگم به جای یک آدرس ، چندین آدرس رو پینگ کنم تا جاهایی که به آدرس های مختلف این وبلاگ لینک دادن همه متوجه به روز شدن این جا بشن و از شر پینگ کردن دستی خلاص بشم. (نتیجه اش این پلاگ-این برای وردپرس شد) ، سوال من تو اون مطلب این بود که مرز توسعه یک نرم افزار تحت وب کجاست ، آیا لازمه مانند چنین تغییراتی توی متن یک برنامه هم اعمال بشه ؟ اصلا باید چه قدر به فکر موارد خاص در طراحی و پیاده سازی یک نرم افزار تحت وب بود؟ و اصولا به چه تیپ از نیازهای جدید کاربران یک نرم افزار باید در نسخه های بعدی اون بها داد.

Now after testing plugin , I face to a question, Should we spread web application in depth like the job I did? Is it really necessary ? Should we force users to follow rules and standards or help them with adding such options to applications?

Matt Mullenweg (سرگروه اصلی تیم وردپرس و صاحب پروژه های دیگه ای مثل ping-o-matic و Akismet ) تو مطلبی به نام " Should we have hidden options? " در وبلاگش یه جورایی جواب سوال من رو هم داده. بحث اصلیشون اضافه کردن یه امکان حرفه ای تحت عنوان about:config (مثل همونی که تو فایرفاکس هست )به وردپرس برای ویرایش ریز تنظیمات وردپرس بود که Alexkingاینجا بهش اشاره کرده بود. نتیجه ای گیری Matt جالبه:

All that said, hard-core developers often need flexibility in the system to expand WordPress to things we’ve never even imagined, and that’s where our plugin system comes in. While we often say no to new options, we rarely ever shoot down a suggested extension to our plugin API. The beauty of this is it allows for near-infinite flexibility in how you interact with the program (there are some amazing plugins out there) while still keeping the core light, clean, stable, and fast. It also makes support relatively painless: “Does it work when you deactivate the plugin?” When someone says they want to do X and it should be core because it can’t be a plugin, 9 times out of 10 I see that as a plugin API bug, not a core bug.