نویسنده: مارک نیوتن
مترجم: فاطمه اللهیاری
شما تلاش دارید تا یک مسئله خاص را با کمک اینترنت حل کنید. فرض کنید که در اینترنت به دنبال تصاویری از گربه‌ها می‌گردید و در بین مباحث بی‌شماری که نمایان می‌شوند سرانجام به لینک مناسبی می‌رسید که به نظر می‌رسد جواب شما را در خود داشته باشد.
این لینک شباهتی به سایت‌های جعلی نرم‌افزاری که ادعای رفع مشکلات کامپیوتر شما را دارند و در آخر هم برای "تعمیر نکردن" آن طلبکار می‌شوند ندارد. اجازه بدهید به طور مثال شرکت مایکروسافت را در نظر بگیریم - هرچند که سایرین نیز به همان اندازه راجع به چیزهایی که قرار است شرح بدهم گناهکار هستند.
روی لینک کشف شده کلیک می‌کنید اما به صفحه‌ای وارد می‌شوید که پیغام “این صفحه منتقل شده است” روی آن قرار شده و هیچ اطلاعاتی در مورد اینکه به کجا نقل مکان کرده موجود نیست.
در حال حاضر بسیاری از محتواهای اطلاعاتی از دیتابیسی سرچشمه می‌گیرند که توسط یک ID منحصر به فرد شناسایی می‌شود و ممکن است منبع آن به هر دلیلی تغییر یافته باشد.
به لحاظ تئوریک حتی اگر این محتوا به سرور domain یا صفحه وب دیگری منتقل شده باشد، صفحه شناساگری که پس از ورود به لینک نمایش داده می‌شود باید ضمن مشخص کردن مکان جدید، مرورگر شما را به سمت آن هدایت نماید.
اما در صورتی که article ID تغییر کرده باشد شما راهی جز جستجوی یک وب‌سایت جدید و یافتن بحث‌هایی که با پاسخ مورد نظر شما مرتبط است ندارید.
یکی از معمول‌ترین دلایل تغییر article ID، تنبلی در کدنویسی و یا جابجایی و یا راه‌اندازی مجدد بسیاری از وب‌سایت‌ها براساس نسخه‌های قدیمی است بدون اینکه هیچ فکر و تصمیمی پشت این کار باشد.
البته هر بار که شما لینک‌های خود را تغییر دهید سایر لینک‌ها تغییری نمی‌کنند و این خود قدرت اینترنت را می‌رساند اما ضعف ناشی از این مشکلات دقیقا به خاطر عدم به‌روزرسانی اتوماتیک لینک‌های ورودی است.
بنابراین تضمین و جایگذاری لینک‌ها در صفحات مناسب و مرتبط یکی از وظایف مدیر وب سایت در برابر بازدیدکنندگان است. البته منظور من از صفحات مرتبط، صفحه نمایش‌دهنده خطای “۴۰۴” با تصویر یک گربه نیست (هرچند باید اعتراف کنم که من همیشه لینک www.ecatsbridge.com/۴۰۴.asp را در این صفحه باز می‌کنم). در واقع صفحه ۴۰۴ باید به عنوان آخرین راهکار ممکن در نظر گرفته شود برای زمانی که یک لینک به حدی تکه تکه می‌شود که هرگز در سایت‌های جدید قابل مسیریابی نیست.
مورد بعدی استفاده از صفحه ۴۰۴ زمانی است که یک سایت که قبلا قابل دسترسی بوده حالا برای ورود به گذر از log in نیاز دارد. اکنون لینک قدیمی شما را به صفحه log in یا عضویت هدایت می‌کند و پس از کامل شدن این کار مجددا به لینکی که قصد مشاهده آن را داشتید برمی‌گردید.
با این حال، در بسیاری از سایت‌ها پس از کامل شدن روند عضویت هم به صفحه مورد نظرتان ارجاع داده نمی‌شوید بلکه پس از ظاهر شدن یک صفحه خوشامدگویی و گذراندن چند مرحله دیگر تازه می‌توانید مطلب دلخواه خود را ببینید.
تمام مشکلاتی که به این لحاظ پیش می‌آید به سبب آگاهی ناکافی در مورد تجربه کاربران است.
سوال اینجاست که اصولا به چه دلیل ID های منحصر به فرد article ها تغییر می‌کنند؟ معمولا دلیل چنین تغییری این است که برخی از فیلدهای موجود در جدول دیتابیس بسیار کلیدی هستند و دیتابیس به صورت اتوماتیک ارزش عددی آنها را تعیین می‌کند و زمانی که شما اطلاعات را به یک دیتابیس دیگر منتقل می‌کنید ارزش عددی این فیلدها به صورت اتوماتیک نوسازی شده و دستخوش تغییراتی می‌گردند.
برای ممانعت از این کار لازم است که ارزش عددی فیلد ID قدیمی به درون یک فیلد مجزا در دیتابیس جدید کپی شده و به طور مثال نامی مانند “oldID” به آن داده شود که البته صفحه کد نیز باید URL هر بازدید کننده را از طریق چیزی مثل:
Request.UrLReferrer.AbsoluteUri
یا
ServerVariables(“SCRIPT_NAME”)
مورد بررسی قرار دهد.
در صورتی که بررسی شما نشان دهد بازدیدکنندگان یک لینک قدیمی را دنبال می‌کنند می‌توانید به جای روبرو کردن آنها با پیغام ناخوشایند “این لینک جابجا شده است” با بررسی فیلد oldID آنها را به مکان درست لینک هدایت نمایید.
اگر شرکت شما ناچاراً با یک مدیر دیتابیس خودخواه سروکار دارد که اجازه تغییر دیتابیس‌های جدید و پرزرق و برقش را نمی‌دهد مجبور هستید که یک جدول بررسی دیتابیس را برای حفظ تمام ID های قدیمی به اجرا دربیاورید تا بتوانید منابع جدید را جستجو کنید.
بدیهی است که این اقدام نیاز به کار دارد اما آنقدرها سخت نیست که برنامه‌نویس‌های تنبل برای انجام آن بهانه‌تراشی کنند. بهترین راهکار برای شناسایی URL بازدیدکننده در هر صفحه جدید ASP.NET می‌باشد.
با قراردادن ASP در مسترپیج سایت این کار به آسانی انجام‌پذیر خواهد بود به‌طوری‌که به سرعت روی تمام صفحاتی که زیرمجموعه مسترپیج هستند ظاهر می‌شود. (در ASP قدیمی شما می‌توانستید این کد را روی صفحه خطای سفارشی قرار دهید اما این کار در.NET اندکی متفاوت است).
اجازه بدهید کمی توقف کنیم و خود سرور وب را بررسی کنیم که اگر شما از ASP.NET استفاده کرده باشید سرور مورد استفاده IIS خواهد بود (البته آپاچی و سایر سرورها نیز قابلیت‌های مشابهی دارند).
زمانی که سرور وب درخواستی از کلاینت کاربر دریافت می‌کند تلاش می‌کند تا با بررسی فایل سیستم آن به حل مشکل URL بپردازد تا وجود صفحه و احتمال جابجایی آن مورد بررسی قرار گیرد.
اگر در این روند هرگونه خطایی مشاهده شود یک صفحه خطا توسط سرور ایجاد می‌گردد که البته این صفحات وب توسط سازنده سرور وب از پیش تعریف شده‌اند و قابلیت دستکاری و ویرایش را دارا می‌باشند.
یکی از بهترین روش‌ها، ارسال فرمان به سرور برای بازگشت به یک صفحه متفاوت – که خودتان آن را نوشته‌اید – می‌باشد تا به این ترتیب بازخوردهای دوستانه‌تری بدست آید (در اینجا شما می‌توانید تا جای ممکن در برابر ظاهر شدن تصویر گربه از خود مقاومت نشان دهید).
این صفحه توسط صفحه‌های مدیریتی IIS برای ASP و HTML ایجاد شده است اما در برخی موارد برای ASP.NET متفاوت است. این صفحات از بسیاری جهات کار شما را راحت‌تر می‌کنند خصوصا اگر دسترسی کاملی به تنظیمات سرور وب IIS در درون برخی شرکت‌های میزیان نداشته باشید.
برای فعالسازی صفحات خطای سفارشی ASP.NET بایستی فایل WEB.CONFIG در سایت شما، جایی که مدخل‌های ورودی پیش فرض به صورت زیر هستند، تحت ویرایش قرار گیرد:
<customErrors mode=”off”/>
با انجام چنین تنظیماتی، در صورت بروز هرگونه خطا، کاربر با یک صفحه اینترنتی پیش فرض روبرو می‌شود که ممکن است مشابه آن را در برخی سایت‌ها دیده باشید (مانند نمونه‌ای که در ادامه خواهید دید.)
برای فعالسازی صفحات خطای سفارشی‌ساز باید مورد زیر را تغییر دهید:
<customErrors mode=RemoteOnly”/>
تنظیماتی که من در اینجا مورد استفاده قرار داده‌ام، سه حالت روشن، خاموش و فقط کنترل از راه دور را به صورت پیش فرض دربرمی گیرد.
در حالت فقط کنترل از راه دور یا RemoteOnly زمانی که شما در خود سرور مشغول جستجو هستید و یا برای رفع یک باگ تلاش می‌کنید هیچ کمکی در خصوص صفحات خطای سفارشی ساز دریافت نخواهید کرد و فقط مشکل صفحات پیش فرض که به لحاظ فنی ارتباط بیشتری با این حالت تنظیماتی دارند مورد بررسی و رفع قرار خواهد گرفت.
البته این نوع از تنظیمات در رابطه با سایت‌های live بسیار مهم و ضروری است و به شما توصیه می‌کنم که حتما از آن استفاده کنید.
در گام بعدی لازم است که صفحات خطای مورد نظر یا سفارشی خود را از طریق فایل web.config به صورت زیر مورد ویرایش قرار دهید:
<customErrors mode=”RmoteOnly”
redirectMode =”ResponseRedirect” Default
Redirect=”GenericErrorPage.htm”>
<error statusCode=”۴۰۴”
Redirect=”۴۰۴.aspx”/>
</customErrors>
در واقع هر سطری از این کدها که کلمه “error” را در خود دارد به منظور مدیریت هر یک از کدهای خطای HTTP قابل تکرار شدن است که در نتیجه آن شما کنترل قابل ملاحظه‌ای روی پیغام‌هایی که کاربران در صورت دنبال کردن یک مسیر اشتباه می‌بینند خواهید داشت.
اکنون همه چیز مانند یک رویا به نظر می‌رسد اما مشکل واقعی زمانی رخ می‌دهد که در صدد بازیابی لینکی که کاربران با دنبال کردن آن با پیام خطا مواجه می‌شوند بربیایید.
برای این کار به اطلاعاتی نیاز دارید که بتوانید کاربران را به صفحه درست و مورد نظرشان در سایت جدید راهنمایی کنید. چنانچه از یک صفحه خطای سفارشی در ASP.NET استفاده کنید به هنگام بازیابی URL مورد رجوع کاربران با مشکل مواجه خواهید شد.
در واقع شما به جای دریافت URL کامل و هریک از پارامترهای مربوط به جستجوی لینک گمشده، یک URL ناقص و فاقد هریک از پارامترهای مهم جستجو خواهید یافت.
به عنوان مثال فرض کنید که کاربر روی لینکی در یک وب سایت دیگر کلیک می‌کند که این لینک با آدرسی مانند www.youroldsite.com/article.aspx?id=۱۲۳۴” به سناریوی اصلی شما لینک می‌شود.
به طور معمول برای بازگرداندن URL مورد رجوع از ابزار Request استفاده می‌کنید که در این حالت اگر صفحه خطای سفارشی شما “۴۰۴.aspx” باشد باید یک بررسی به صورت زیر انجام دهید:
Request.PathwithQueryString()
که پس از آن با جمله زیر مواجه خواهید شد:
۴۰۴.aspx?aspxerrorpath=http://www.youroldsite.com/article.aspx
در واقع در دنیای واقعی یک URL رمزگشایی شده برای ماشین قابل خوانش است اما من با حذف این مرحله آن را برای انسان هم قابل فهم‌تر کرده‌ام. همانطور که می‌بینید “?is=۱۲۳۴” که آرتیکل واقعی مورد علاقه کاربر را نشان می‌دهد مفقود شده است.
بنابراین زمانی که کد صفحه خطای سفارشی ساز شما کاربر را به یک صفحه درست هدایت می‌کند هیچ ایده ای در مورد آرتیکلی که کاربر در حقیقت به آن علاقه‌مند بوده است وجود ندارد. کاش می‌توانستم راهکار گویاتری ارائه بدهم اما هیچ راهکاری نیست و من از یک راهکار کلی که در اغلب سناریوها جواب می‌دهد استفاده می‌کنم.
سه روش مهم برای جابجا کردن وب سایتی که مسبب شکسته شدن لینک شده است وجود دارد و من فرض را بر این می‌گذارم که ID های متفاوت آرتیکل ها هم تغییر کرده‌اند.
اگر مدت زیادی از مالکیت شما بر دامنه قدیمی گذشته است پس در مورد لینک‌های شکسته شده‌ای که کاربران با آن روبرو می‌شوند کاری از دستتان برنمی آید.
اما اگر هنوز مالکیت آن را در اختیار دارید یکی از سه حدسیات زیر درست است:
۱. صفحات مشابه یکدیگر هستند اما هم اکنون میزبانی آنها روی دامنه متفاوتی قرار دارد.
۲. دامنه یکسان است اما نام‌های صفحه و یا ID های آرتیکل تغییر کرده‌اند.
۳. صفحات و ID های آرتیکل یکسان هستند و دامنه تغییر کرده است.
شما می‌توانید صفحه‌های هدایت کننده را در domain قدیمی نگهداری کنید اما برای حفظ بقای آن شاید بهتر باشد که domain قدیمی را به سرور وبی که domain جدید در آن است ببرید تا هر دوی آنها در صفحات و وب سایت یکسانی گرد هم آیند.
شاید این مسئله برای کاربرانی که به دنبال وب سایت آشنای خود می‌گردند کمی گیج کننده باشد که به یکباره به سایتی با ظاهر کاملا جدید هدایت شوند اما این کار برای کدگذاری در مسترپیجی که تشخیص می‌دهد کاربر از کدام URL وارد شده است، ایده بسیار خوبی است.
در صورتی که آنها از طریق domain قدیمی وارد سایت شده باشند قبل از نمایش صفحه جدید، یک صفحه حاوی توضیحات را مشاهده خواهند کرد. انجام این کار هم به سادگی از طریق Request Object امکانپذیر است.
اما برای عملی شدن این روند لازم است که نام صفحات جدید در تمام صفحات داینامیک، مشابه با نام صفحات سایت قدیمی باشد تا بتوان در جستجوها روی این پارامترها متکی شد.
هیچ مسئله ای نیست اگر برخی از این صفحات جدید خالی و فقط حاوی کد هدایت‌کننده باشند زیرا در صورتی که نام صفحات مشابه نباشد کاربران خطای “۴۰۴“ را دریافت خواهند کرد و با صفحه خطای سفارشی شما مواجه خواهند شد. همانطور که پیش از این هم توضیح دادم در غیر اینصورت شما به طور کلی URL مورد پیگیری کاربران را از دست خواهید داد و در مورد article ID هم اطلاعاتی پیدا نخواهید کرد.
این نوع درجه‌بندی یا رنکینگ به جهت اطمینان از اینکه لینک‌های شکسته یافته شده با درخواست “۳۰۱” HTTP مواجه می‌شوند برای موتورهای جستجو بسیار مهم است و به موتورهای جستجو اعلام می‌کند که صفحه مورد نظر برای همیشه جابجا شده و یا به سبب یک خطای موقتی فعلا در دسترس نیست.
این کاردر ساختار سرور وب انجام می‌پذیرد برای کسب اطلاعات در مورد ساختار IIS۷ می‌توانید از آدرس اینترنتی www.pcpro.co.uk/links/۲۲۶wa۱ و برای IIS۶ از آدرس www.pcpro.co.uk/links/۲۲۶wa۲ کمک بگیرید (در مورد آپاچی هم می‌توانید با تغییر فایل HTACCESS نتیجه مشابهی را ببینید).
پس از این تنظیمات موتورهای جستجو می‌توانند صفحات را شناسایی کرده و دوباره به سمت آن هدایت شوند که ثبات چنین وضعیتی به شناسایی صفحات برای دفعات بعد کمک زیادی خواهد کرد. البته چنانچه نگهداری درجه‌بندی SEO قبلی برای شما دردسرساز نباشد می‌توانید از این مرحله چشم‌پوشی کنید.
توسعه وب یعنی چه؟
یک روز غروب من با دوست خوبم استیو که برای شرکت بریتیش تلکام کار می‌کند سرگرم گفتگو بودیم و او از من پرسید: “تو مفهوم توسعه وب را چگونه تعریف می‌کنی؟” در واقع جرقه این اظهار نظر ناشی از شنیده‌های او مبنی بر قرار گرفتن دروپال و Dreamweaver در فهرست A مجله PC Pro به عنوان ابزارهای بسیار مناسب جهت توسعه وب بود.
در حال حاضر مطمئن نیستم که بتوانم هر نوع سیستم مدیریت محتوا (CMS) را به عنوان یک ابزار توسعه وب معرفی کنم. من آنها را به عنوان چارچوب‌هایی برای توانایی ایجاد وب‌سایت‌ها قلمداد می‌کنم.
از نظر من ایجاد ماژول‌های یک CMS که غالبا برای ساخت یک وب سایت واقعی در PHP نوشته می‌شوند، با یکدیگر ادغام شده و نیازمندی‌های عملیاتی وب سایت‌ها را فراهم می‌آورند.
انجام این کار سبب می‌شود تا Dreamweaver، Visual Studio، Eclipse و بسیاری از محصولات مشابه به ابزارهای مناسبی برای توسعه وب تبدیل گردند.
البته با وجود این واقعیت که بسیاری از روش‌های قدیمی ایجاد وب‌سایت هم اکنون با CMS جایگزین شده‌اند اما هنوز هم نیاز به ابزارهای خام کدنویسی احساس می‌شود و به اعتقاد من کاربری CMS بیشتر در مبحث “ایجاد” وب سایت معنا می‌یابد تا “توسعه” آن.
شاید من در این مورد دچار اغراق شده باشم اما دانش و مجموعه مهارت‌های لازم برای ایجاد یک وب‌سایت مطمئن و بروز، از طریق کد خام بسیار متفاوت تر از مهارت‌های مورد استفاده در CMS برای خلق یک وب‌سایت می‌باشد.
من می‌توانم کاملا در مورد اینکه کدنویسی یک وب‌سایت از روی scratch این روزها نفع چندانی ندارد با شما به بحث بنشینم چراکه با چند ماژول پلاگين برای یک CMS می‌توانید به بسیاری از خواسته‌های خود برسید.
با وجود اینکه هم اکنون اغلب سایت‌ها از سیستم CMS بهره می‌برند اما انعطاف‌پذیری برنامه‌نویسی یک وب‌سایت از طریق scratch جایگاه خود را دارد. علاوه براین، باگ‌زدایی کدهای شما در scratch بسیار آسان‌تر صورت می‌گیرد تا اینکه همیشه بین انبوهی از ماژول‌های CMS که توسط افراد متفاوت نوشته شده‌اند و دلخواه شما نیستند سرگردان باشید!
مرگ Expression
یکی از محبوب‌ترین ابزارهای توسعه وب از نظر من، به خصوص برای نوشتن CSS، مایکروسافت اکسپرشن وب (Microsoft Expression Web) است و خبر توقف توسعه و پشتیبانی از آن به همراه بسیاری محصولات دیگر در سوئیت Expression برای من بسیار ناراحت کننده است (www.pcpro.co.uk/links/۲۲۶wa۳). در حال حاضر همه آنها به صورت دانلود رایگان موجود هستند و ارزش دارد که هارد دیسکتان را با چنین ابزارهایی پر کنید.
در حقیقت Blend که همیشه آچار فرانسه سوئیت Expression به حساب می‌آمده طراحی XMAL برای Silverlight و توسعه موبایل را انجام داده است. همراهی کنونی Blend و Visual Studio حاکی از قرار گرفتن این ابزار در بهترین جایگاه ممکن است.
مایکروسافت زمان زیادی را صرف خلق رقیبی برای DreamWeaver کرده است و با اشتیاق بی‌اندازه‌ای تلاش کرد برای این منظور طراحان را با شبکه گسترده توسعه دهندگان همراه کند.
بنابراین داستان کنفرانس‌های MIX که همیشه الهام‌بخش طراحان بودند اکنون به پایان رسیده است. به نظر می‌رسد که مایکروسافت به دوران قدرت خود در بین جامعه توسعه‌دهندگان نرم‌افزارها بازگشته است.
روی متر و اندازه
من اغلب در خارج از اداره کارهایم را انجام می‌دهم و گاهی فقط می‌توانم از طریق یک سیستم کند یا سیستمی که به خاطر مصرف ترافیک بدهکاری دارد یا اینترنتی که از شدت گرانی اشکم را درمی‌آورد به امور خود برسم.
شاید هم در آخر مجبور بشوم که یک سیستم ماهواره‌ای در موتورخانه منزلم نصب کنم. در تمام این موارد من تنها کاری که از لپ‌تاپم انتظار دارم دانلود کردن به‌روزرسانی‌های حجیم است اما در این بین آن اینترنت را برای هر کاری غیر از آنچه که خواسته من است به کار می‌گیرد.
اما جای بسیار خوشحالی است که ویندوز ۸ توانایی این را دارد که هر نوع ارتباط شبکه را در قالب ارتباط مقیاس سنجی شده (metered connection) به سیستم شما اختصاص داده و به این ترتیب از میزان ترافیک بکاهد.
یک metered connection قادر است به‌روزرسانی‌ها را به ترتیب اولویت دانلود کند. البته این راهکار مایکروسافت هنوز هم به مرحله پختگی کامل نرسیده است.
در حال حاضر من دوباره به استفاده از نرم‌افزار مدیریت پهنای باند Cucusoft Net Guard روی آورده‌ام که ضمن کنترل مقدار مصرف داده‌ها، در صورت بالا بودن میزان فعالیت هشدار می‌دهد. چیزی که من حقیقتا به آن نیاز دارم فایروالی است که بتوانم آن را به سادگی برای تایید ترافیک ورودی و خروجی مورد نظر خودم تنظیم کنم و این تنظیمات به راحتی هم قابل بازگشت باشند.
فایروال ZoneAlarm (www.zonealarm.co.uk) تا حدی به این ایده نزدیک است و به شما اجازه می‌دهد تمامی مصارف اینترنت را متوقف کنید اما اگر این تنظیمات برای هر پروفایل به صورت مجزا انجام گیرد فوق العاده خواهد بود.
در این صورت می‌توان، به استثنای مواقعی که قرار است با وی‌پی‌ان کار کنید، جستجوهای اینترنتی مجاز را مشخص کرد و بین پروفایل‌های مختلف جابجا شد.
معرفی یک نرم‌افزار جدید و مفید
Xara9 اگر کدسازی سایتی که مشغول ساختن آن هستید توسط scratch یا CMS انجام نشده باشد Xara Web Designer یک جایگزین بسیار مطلوب خوهد بود (www.xara.com/uk). نسخه ۹ این ابزار که اخیرا عرضه شده است از HTML5 پشتیبانی می‌کند و برای طراحی ابزارهای موبایل و فونت‌های وب کاربرد دارد اما کم بودن مشخصه‌های جدید در نسخه جدید و قیمت ۴۰ یورویی آن برای ساختن وب‌سایت جزو معایب آن است.  |
درباره نویسنده: مارک نیوتن، مدیر شرکت اینترنتی Ecats (Electronic CATalogueS) است که به طور تخصصی در زمینه راهکارهای مبتنی بر اینترنت فعالیت می‌کند.
منبع: نشریه PCPro، آگوست ۲۰۱۳
دریافت لینک صفحه با کد QR