Arcane Lore

Вчера в края на проследяването на една дългичка поредица уеб-препратки съвсем случайно забелязах, че се продават преходници с вградено накланяне или изместване на обектива. Ако някой си е казал “пак тия руснаци”, познал е — Аракс са ги пуснали и са страхотна идея, типично по руски са “хак”. Руснаците са хакери, отдавна им го признаваме. И то не само в ИТ, и във фотографията го доказват с не една хитри хрумки, които се оказват и много полезни. Като например “одуванчик”-а (“глухарче”, платка за потвърждение на фокуса на преходници от М42-обективи към канонски тела). И като сега тези тилт- и шифт-адаптери.

Хубавото им е, че са на достъпна цена, а ако човек закачи отпред им качествен средноформатен обектив, комбинацията може да е по-качествена от предлаганите готови решения за тилт-шитф. Особено за slr-системи, различни от канонската — единствено Канон имат някаква традиция в тези обективи и в линията им има наистина добри T/S. Никон наскоро май пуснаха един нов T/S, но тук-там се чуха недобри неща за отношението му оптика/цена, а това е далеч от отзивите за двойката тилт-шифт серия L, на която могат да се радват канонците.

За мое съжаление не само Никон не са си поставяли като цел допълване на системата с тилтшифт-обективи. Пентакс си нямат пък никакъв, изключая един-единствен шифт-обектив, K 28/3.5 Shift. Има и един прототип на тилт-обектив, но той никога не е стигнал до поточната линия — M 32-39/2.8 Flexi. Всъщност не съм сигурен дали това е тилт, почти нищо няма в мрежата за него. Но все тая — колекционерска рядкост е, а и е само прототип, така че е неоткриваема колекционерска рядкост. ;)

Та другото хубаво на тия преходници е, че с добър средноформатен обектив на практика се превръщат в качествен тилт или шифт, който може да се поставя на различна система. Имат варианти за Nikon, Canon FD и EOS (макар че точно за Канон само цената им може да е привлекателна), Minolta MD и Dynax, Contax/Yashica, Leica (тук пък който е дал пари за Лайката, едва ли ще търси вече евтиното решение), всички системи с M42 и, разбира се, Pentax.

Мания направо — на апарат със сменяема оптика се поставя тилт или шифт със сменяем обектив. Няма защо човек да се ограничава с качествата на един или два фабрични T/S-а, а може да си избира с кой обектив да излезе днес, за да снима архитектура с шифт-а си, примерно. Избира си някой хубав обектив и готово. Хоп — в todo-то (тъй де, tohave-то).

От вчера някъде около 11 и половина до 13:25 преди малко. Към 14 часа, прекъснати на два-три пъти за да взема още нескафе от кухнята. Административен раздел на сайт, само кода с готов дизайн и начисто. Отдавна не бях работил така, а и напоследък все се захващам с разни по-мащабни и объркани начини за правене на иначе прости сайтове.

В 13:25 компютърът се рестартира - май много жежко му идва да работи толкова дълго и нещо прегрява. Тъкмо беше бавен рестарт, с проверка на дяловете и успях да се разсея в кухнята, да си взема нещо за хапване и да си побъбря с котарака :)

Почти всичко стана, имам само няколко неработещи форми за качване на файлове - не разбирам защо не винаги предават самите файлове. Сигурно съм забравил как се прави, а четенето на документация за познати неща е върло скука. Абе ставам още, дето се вика :)

Наскоро писах как можете лесно и бързо да инсталирате и пуснете в употреба уеблог-системата WordPress на хостинг-място, осигурено от доставчика dom.bg. Причината да смятам това изобщо за полезно по някакъв начин е, че въпросният хостинг е много евтин. Има по-добри, не казвам, че е добър. Макар на всички мои писма да е било отговаряно винаги в рамките на най-много няколко часа, дори и привечер и нощем. Но все пак този хостинг има едно отличително качество и то е ниската цена. Не, изобщо не рекламирам този доставчик! Достатъчно съм се измъчил с услугата му, за да пожелавам такива кахъри на хората… Причината да пиша тези малки “спасяващи” решения е, че сигурно има и други хора, които като мен вече са се подлъгали и са си купили хостинг именно от dom.bg. Надявам се тези неща да помогнат на някого, който е при такъв или подобен доставчик, да осъщетвява идеите си в мрежата поне малко по-лесно и удобно.

——

Ако сте опитвали да инсталирате MediaWiki на акаунт в dom.bg, сте забелязали, че се появява същият проблем, както при WordPress - след инсталация страницата не се зарежда, връща се грешка 500. Причината отново е във факта, че PHP се изпълнява не като модул, а през CGI. Работил съм с повечето от свободните проекти за малки уеб-сървъри и много често ми се е налагало да пускам PHP през CGI. Но винаги, когато натоварването е било по-голямо, тоест въпросното php не е било “за кратко”, “инцидентно” или “единствено”, съм сменял малкия сървър с Apache. Именно защото за Apache има модули за такива неща. Използват повторно заделената си памет и т.н. Не мога да си представя как работи уеб-сървър в условия на голямо натоварване (защото каквото и да си говорим, dom.bg е един от масовите доставчици, доста страници търкаля това CGI…) с PHP, извикван всеки път през CGI, за всяка php-страница.

Но все едно, ето как да си пуснете MediaWiki на dom.bg:

Отваряте файла /includes/OutputPage.php и закоментирате реда

header(“HTTP/1.1 {$this->mRedirectCode} Moved Permanently”);

При мен беше под номер 427. Под него добявате следния ред:

header(“Status: {$this->mRedirectCode} Moved Permanently”);

Закоментирате и реда

header(“HTTP/1.1 304 Not Modified” );

При мен беше под номер 122. Под него добавяте следния ред:

header(“Status: 304 Not Modified” );

И след това MediaWiki вече е готово за “пълнене” със съдържание. Само първата промяна ще е достатъчна, за да “тръгне” сайтът. Но променете и втория указан ред, за да избегнете всички възможни връщания на грешка 500 по такава “cgi”-причина.

Отново, както ии при WordPress, може да се постави кратка проверка на местата, където се изпращат http-заглавките и да се изпраща адекватен отговор, в зависимост от това дали PHP е като модул или е през CGI. Ако има интерес, ще публикувам такава проверка и може да пиша на разработчиците да я добавят. За улеснение на обновленията на версиите за такива cgi-потребители. Но мисля че засега с такъв малък хак всички ще се справят. А и dom.bg може да обновят някой ден сървърите си. Не само че са през CGI, ами и версиите на софтуера им са едни… стари, де… Ама няма значение, тяхна си работа… ;)

Смятам да не пиша повече за този проблем. Принципът ви е ясен и сигурно има страшно много други програми, които ще връщат грешки в такава среда. Ясно е какво трябва да се промени. Ако имам друг хак за “справяне” с dom.bg, принципно различен, тогава ще пиша.

Преди време Владо Герджиков имаше проблеми с доставчика на хостинг “dom.bg”. Понеже и аз съм също там (все още; засега май реших голяма част от проблемите и не ми е чак съвсем некомфортно, та може да остана до края на платения период…), реших да споделя един малък хак за хората с Wordpress.

На dom.bg PHP работи не като модул на уеб-сървъра, а като скрипт през CGI. Причините няма да коментирам - те си знаят защо са решили така. Не зная колега, който ще сложи PHP през CGI на такъв голям сървър, но все едно - това е положението.

Та един от основните проблеми при работата с dom.bg е именно този. Повечето готови системи, писани на PHP, най-често изобщо не правят проверка дали се работи през CGI. Обяснявам си го с предположението, че почти никой не би се сетил, че има публичен хостинг, който да пуска PHP през CGI. Нещо по-“екзотично” като Ruby например може и да се пусне, но пък PHP… Макар да си има модул и за Ruby. :)

При инсталиране на Wordpress на въпросния хостинг всичко минава правилно до момента, в който трябва да заредите сайта си. Тогава се връща грешка 500 (internal server error). Иначе администраторският интерфейс си работи, всички настройки и редактирания - също. Проблемът се появява при зареждане на основния сайт. Логовете на dom.bg не са видими от потребителя, можете да ги изискате с писмо до поддръжката, но в този случай не си правете труда. Ето решението…

Ако инсталирате Wordpress на акаунт към dom.bg (или изобщо някъде, където PHP работи през CGI, отворете файла /wp-includes/functions.php и намерете мястото със следните два реда:

@header(“HTTP/1.1 $header $text”);

@header(“Status: $header $text”);

Във версията, която днес инсталирах (2.0.2 - последната към момента) тези редове са с номера 2170 и 2171. Но с търсене ще ги намерите - единствени във файла са.

Това, което ще реши проблема ви, е закоментирането на първия от тези редове. Сложете коментар (“//”) пред реда, който изпраща HTTP/1.1 заглавка. Първият ред е за PHP като модул, а вторият - за PHP, изпълняван през CGI.

Не зная защо в самия код на Wordpress не са добавили точно на това място една кратка проверка как се изпълнява PHP и след това просто да се изпраща съответния ред. Може би това е възможно решение на бъг в Wordpress, но рядко бъркам и надничам в кода на WP, за да кажа със сигурност дали е бъг и дали трябва да се добави провеерка. Или може да минем само с тоози малък хак за такива “странни” хостинги като родния dom.bg. Ако някой има представа и му се занимава да чете по-подробно кода на WP, нека каже. Ако проверката е удачна, може да пратим на разработчиците поправката. Става дума за ред-два “if-then-else” проверка ;)

Приятно блогване ;)