1

 <?php dsm ($переменная);  ?>

позволяет посмотреть содержание любой переменной или любого массива в потрясающе удобном виде, на самом деле это альтернатива функции print_r, которую можно использовать в качестве плагина на любом сайте, не только drupal. Вот ссылка http://krumo.sourceforge.net/

В итоге на мою злочастную ссылку отдельным слоем сверху (через position: absolute) была наложена прозрачная кнопка из input type="hidden".

Вот так: <div style="width: 100px; height: 20px;" ><input type="file" /></div>

Т.е. это был div фиксированного размера, в нем поле input type="file" с большим шрифтом (чтобы сама кнопка обзор была большая), инпут перекручен так, чтобы видна была только кнопка (тогда cursor: pointer и пользователь не может тыкнуть в поле), т.е. инпут гораздо больше чем div, просто находится внутри него кнопкой попадая в то что из-под дива видно.

И разумеется все это счастье прозрачное. И вуаля! Пользователь думает что кликает на ссылку, а на самом деле кликает на кнопку - и наше менюшка выбора файла тут же появляется на экране.

теплый дом .

var el = document.getElementById('element');
el.parentNode.removeChild(el);
document.getElementById('destination').appendChild(el);

Система платная, хотя есть и nulled версии вроде как. На сайте движка www.ilance.com описано как все там замечательно, все отлично настраивается и вообще убермегатру. Маркетологи как обычно постарались и описали все в лучших традициях, даже подготовив демки.

К сожалению мне довелось увидеть эту систему не со стороны красивых админок и замечательных обзоров, а изнутри.Честно говоря я очень давно программирую и мне нравится колупать именно чужой код, это очень обогащает идеями, и я не ожидал увидеть там четкой объекто-ориентированной вылизанной системы, но некоторые решения просто убили на месте... Стоит отметить что iLance сам по себе по тому_что_он_может и что_там_можно_настроить довольно функционален. Действительно, на уровне самой цмски заложена мультиязычность с легкой возможностью настраивания через файлы конфигурации. И первое что отвалилось в процессе установки русской версии была именно она. В программировании мультиязычных сайтов есть 2 основных подхода:

• Каждая языковая версия - это логически отдельный сайт со своей внутренней системой страниц, данных и т.п;
• Структура данных одна и та же, но чуть ли не каждая запись сопровождается полем с идентификатором языка.

Ребята же решили не париться со всеми этими сложными ссылками и прочей лабудой и просто продублировали каждую запись с языковым префиксом: title стал title_en и title_ru к примеру. И действительно зачем напрягаться, если title_en заполнен - значит английская, а нет - русская. И я честно понимаю разработчиков. Если бы я знал, что на сайте будет 2 языковые версии и только они - то в рамках баланса время/деньги действительно не стал бы заморачиваться. Принцип "делай то что нужно, а не то что может быть понадобится потом когда-нибудь а может и нет" знаете ли. Но парни явно забыли, что iLance - это система на продажу. И я не буду писать про расход памяти, про то какая задница добавить новую версию через тупое дублирование всех полей везде с дополнительным языковым префиксом - это хрен с ним, потому что даже эти 2 несчастных языка система не могла сожрать без глюков: Регионы глючили и глючили жестоко... И тут начался мой выход.

Первая попытка установить сайт на локальную площадку с треском провалилась. Мне искренне интересно, какой индусский долбоеб указал для половины полей в каждой таблице not null default null ? Но на удивление это работало на "живом" сайте, и не работало у меня. Любая попытка что-то записать в базу падала на инсерте когда такие поля были не заполнены. А система ведь на продажу, должна запускаться везде, ага Признаюсь честно, я не осилил переколбасить все эти поля, успел только то, что касалось моей работы. И как только у меня это получилось полез в код. Тут меня ожидал большой сюрприз

Как известно, многие продукты, которые выставляются на продажу пишутся на функциях без ООП. Это делается для того, чтобы система действительно работала абсолютно везде, при любой сборке php и на любом сервере. Если это не учитывается - строится мощная объектно-ориентированная архитектура приложения, все абстрагируется, пишутся требования к серверу и т.п. Но не тут. Действительно нет. Разработчики iLance настолько крутые ребята, что используют ООП в лучших традициях Индии. Первым делом я встретил антипаттерн God Object. Объект $ilance действительно настолько крутой что управляет и переменными реквеста, одновременно он и шаблонизатор и хранит настройки и вообще (я до многого не добрался, тут все его фичи описать не могу). Есть у объекта-бога и пару приспешников - объекты некоторых сущностей (функционально это не объекты вообще, а статические либы), некоторых означает примерно 10% сущностей, все же остальное хранится в файле с функциями на 4 тысячи строк и тотальной копипастой.

К слову об объектах. В php никогда не было толком никаких соглашений. Да, были попытки, но такого явного как скажем в java чтобы только camel hump и все, не было. И каждый мог выбрать то что ему нравилось. Но называть классы с маленькой буквы через подчеркивание, увольте.

А ужас нарастал. Вместо хоть какой-нибудь пародии на контроллеры и хотя бы уже черт с ним я бы смирился, чтобы отдельная страница отрисовывалась в отдельном php-файле без классов и функций. Пусть говногод ну да и ладно, в одном месте хотя бы, а значит - разобраться можно. Вместо этого меня встретили файлы по 3-5 тысяч сторок php кода, в очень редких местах были вызовы функций из либ (примерно таких же по объему и каше). Копипаста наполнила проект чуть более чем полностью. Некоторые записи вставляются через либы, а апдейтятся тут же через sql-ник. Кстати, очень много sql-ников и никакой абстракции под их генерацию даже для простейших тупых запросов из серии select * from table where че_то_там. Рендеринг страниц с помощью шаблонизатора идет вперемешку с расово индусским спагетти-кодом.

Кстати о шаблонизаторе. В iLance он есть, но лучше бы его не было. Все что он умеет - это условия (if-else) и циклы (loop). Кстати, я так и не нашел как же в цикл вставить условие а все потому, что эти шаблоны никуда не транслируются. Обычно ж как, если есть псевдоязык - он транслируется в php файлик, который затем каждый раз подключается (чтобы не транслировать его еще раз) и уже по внутренностям этого файла можно догадаться о том как нужно писать в шаблонах чтобы оно работало. Но сохранения результатов нет, они есть в памяти черт знает где и потом по всему этому счастью происходит eval. Вот так-та.

Казалось бы, что уже после всего, что я увидел, сложно наляпать еще где-то. Я искренне в это верил пока не узнал как в iLance происходит работа с css. Надо отметить что во всех проектах, с которыми я работал (а это порядка 80 штук от самых мелких до монстров) я не встречал такого. Разработчики iLance действительно гении, они первые придумали хранить стили в базе данных! Нет, они не хранят там целые файлы стилей, это было бы еще полбеды. Каждый css-класс - это запись в базе. Имя записи к примеру .blog и код стиля padding: 0px; к примеру. А потом это все собирается в css-ку, которая ложится в кеш и подключается при запуске страниц. Редактирование этого всего - только через админский интерфейс. А в нем мегафишка! : область видимости стилей можно указать. Например можно чтобы определенный стиль был и в админке и на фронте, а другой только на фронте. Почему нельзя было сделать 3 файла скажем global.css, front.css и admin.css, как делают все нормальные люди? Да потому что там есть подсказки для стандартных стилей, наверное для того чтобы люди непросвященные в css легко могли добавлять и менять там что-то свое. Возможно, разработчики и не знали, но мы то точно знаем, что ни один нормальный человек, который в этих ваших стилях ничего не понимает никогда в жизни не попрется туда что-то править, а если уже человек решил разобраться в css, то в самих файлах ему будет куда проще (хотя бы потому что все доки именно по .css-файлам, а не по хренпойми чему), не говоря уже о профессиональных верстальщиках, которые скорее всего и будут делать редизайн в случае чего.

Подводя итоги моей работы с ее величеством iLance CMS хочу отметить, что, хотя она и ужасная внутри, работать с ней можно. Если ничего не нужно менять - работать она будет как 95% аналогичных систем по всему интернету. Парням из iLance искренне хочется пожелать хотя бы иногда включать мозг и прочитать пару книжек по ООП, их менеджерам - никогда не нанимать студентов, тем, кто прочитал эту статью и думает работать с этим или нет, подсказать уже нечего - вы и так молодцы, что не ограничиваетесь только тем что пишут на сайте самой cms-ки о ней, ну а программистам - никогда не повторять этих ошибок.

Вконтакте Merchant в зипе

З.Ы. Код на 115 строк - ну не с руки в посте его писать.

З.Ы.Ы. если кому помогло - поставьте + в коментах просто ради интереса

Но недавно оказалось что можно. На примере:

$input = Input_Factory::factory('text'); /*@var $input Input_Text*/

И ура, подсказки работают

Ну традиционный понятно:

INSERT INTO sometable (`field1`, `field2`,  `field3`)  VALUES ('value1', 'value2', 'value3');

А альтернативный как и UPDATE:

INSERT INTO sometable SET `field1`='value1' , `field2`='value2', `field3`='value3';

Суть ситуации в том, что люди намеряно сводят работу с базой данных до уровня insert, update, select, delete, создавая особо извращенные варианты доступа к этим самим данным. Любые - лишь бы не SQL. В итоге, понятное дело, без извращений в таких вещах очень сложно сделать простые с точки зрения запросов вещи. Ну например, счетчик посещений сайта и например ORM.

Алгоритм какой будет?

1. Выбрали данные;

2. Увеличили на 1;

3. Сохранили данные.

А что если на сайт почти одновременно зайдут 2 пользователя? Причем до шагов этого алгоритма они дойдут параллельно и в одно время. Т.е. 1-й делает выбор данных, потом второй, потом первый - увеличивает счетчик и т.п.? понимаете?

В самой базе все проще - UPDATE четотам SET `count`=`count`+1 WHERE четотам. И никаких глюков - потому что запросы будут выполняться последовательно.

Когда же копаешь глубже о причинах таких диких абстракций - оказывается, что все для того, чтобы:

Если заказчик захочет сменить базу данных скажем с MySQL на Oracle - то мы всего лишь переписали бы конфиг и все запалило на ура вместо того, чтобы переколбашивать весь сайт.

Я однажды не выдержал и поспрашивал всех кого знал, а сталкивался ли кто-нить из них с такой задачей - и оказалось что такое всплыло 1 раз на примерно 500-700 проектов, в которых участвовали опрошенные

Проблема эта в мире по на заказ (при разработке пакетных вещей - другие законы совсем, не нужно путать эти миры) - надуманная и определенно не стоит тех мучений и костылей, которые приходится делать в подобных системах.

Надеюсь, кому-то этот пост поможет перестать наступать себе на яйца при разработке. Помните: какой бы ни была по сложности задача смены СУБД - вы или фирма все равно на ней нагреетесь - заказчик хочет - заказчик платит

А еще и вот так:
var val = 'Индикатор ядовито\
гидролизует сернистый газ,\
таким образом за синтез';

Не сказать, чтобы было гораздо читабельнее, но есть и такой вариант

Но вот недавно столкнулся с интересной ситуацией - поле varchar - там лежат числа. И получается что-то вроде:

select '33' > '5';

причем выбирает есесна 0 т.е. фолс, т.к. сравнивает строки. Такое вполне очевидно, но привыкаешь постепенно что с нестрогой нет проблем вот тебе и такое

1. Email в качестве логина -  пожалуй, первое место в списке тупых идей. Сама идея такого подхода как раз-таки направлена на то, чтобы пользователю было проще регистрироваться. Типа вбивать меньше данных и все такое. Но на деле получается как раз наоборот - пользователь регистрируется не только на этом сайте, причем в большинстве случаев он вводит логин и пароль и ни разу не мыло в качестве логина. Он привыкает к этой паре логин-пароль и для него вбивать емэйл просто неочевидно, непривычно, не говоря уже о том, что если мыльников штук 5 - то какой именно был вбит при регистрации - вопрос достойный Что? Где? Когда?. Ну а если в форме авторизации еще и не подписано что вводить надо емэйл - ууууууууу
2. Ограничения на выбор пароля - секъюрность - это круто, несомненно. Только вот пользователь привыкает к своей привычной паре логин-пароль. А вот если привычный пароль не проходит ограничения, выбирает новый, который с 90%-й вероятностью забудет тут же как вбил. На следующем заходе запросит восстановление - и пароль будет пылиться на мыле и каждый раз он будет заходить на мыло, смотреть пароль и вставлять в форму Вы считаете, что ваш аккаунт на вашем сайте - самое важно в жизни пользователя? ну-ну ) Безопасность - это важно, когда нужно. Пусть пользователи сами решают, важен для них ваш сайт или он достоин пароля 12345.
3. Капча + подтверждение email-а в регистрации - одной капчи с головой хватит чтобы вырубить ботов. Да есть метод леммингов для ее обхода, но много ли кому не влом его прикручивать? С подтверждением по emailу (активацией аккаунта) есть вечная проблема - обязательно у какого-нить письма не будут приходить. Или они в спам уйдут или еще какая-то фигня случится - неважно, так есть и будет. Не лучше ли высылать письмо со ссылкой на отписку, если ввели не правильный мыльник, чем на активацию? Да и настолько ли важно знать мыло пользователя для вашего сайта?
4. Нераспознаваемая капча - кто-то криворукий создал новый тип капчи и все начали его пользовать. Не знаю видел ли кто - но я, человек из плоти и крови, вбиваю ее верно раза с 10-го.
5. Капча без возможности перезагрузки - какой бы капча не была простой - обязательно однажды она сгенерит что-то ну просто совсем нечитаемое. А если пользователь уже вбил всю анкету - перегружать страницу не есть круто, ибо чревато потерей данных в некоторых браузерах.
6. Лишние обязательные поля - какое вам дело как меня зовут или где я живу? Хочу введу хочу нет и нефиг делать это обязательным, поэтому для вас зовут меня "вапва" и фамилия "водаплвопвпвпавап".
7. Малое ограничение на количество безпроблемных попыток ввода верного пароля - например, после 5 паролей начинает вылетать опять же капча или пишет типа подождите 20 минут. Лично у меня паролей штук 20, не меньше, и юзал я разные в зависимости от ситуации, вначале одни, потом другие и т.п. за лет 10 накопилось немало вариантов... А тут 5 - и потом мучайся... а в сочетании с п.4 - уххх  как весело авторизоваться становится...
8. Блок при N неверных попыток авторизации - тут скорее дело не в идее блокировать доступ к аккаунту на время если кажется, что подбирают пароль, а в кривой реализации этого некоторыми товарищами. Так как куки чистятся - надо учитывать ip, с которого пытались это сделать, иначе кто угодно набьет другому N попыток авторизоваться всяким шлаком и заблочит ему на время аккаунт.

С чего начать? С больших или с маленьких задач?

Обычно начинают всегда с больших. И так в целом абсолютно здраво делать, когда проектируется новый сайт или вы знаете систему отлично. На маленькие задачи надо меньше сил, а если вначале сделать мелочь - то на большое не всегда останется рвения. Да и если система создается новая - то вначале надо сделать "скелет", а уже потом навешивать мышцы и кожу

Но такой подход абсолютно не оправдан в случае, если вы вносите изменения в систему в которой нифига не разбираетесь. В таких случаях лучше начинать с конца.

Например, пришел проект написанный фиг знает на чем, фиг знает кем и когда. Что внутри - непонятно. Делаем мелкий таск - изменение надписи. Дело пятиминутное - тупо прогнать поиск по коду (и базе если по коду не найдется) по этому слову - и поменять его. Задачу сделали - и уже кое-чему научились, например, как устроена система локализации, есть ли она вообще. Какие шаблоны есть в коде. Т.е. решение мелкой задачи помогло попутно разобраться с проектом и узнать что-то о нем, без того чтобы специально колупать его и смотреть что там и где. И так далее - от мелкого к крупному.

Такой подход позволяет убить сразу 2-х зайцев:

1. Тратится минимум времени на изучение архитектуры проекта;
2. Всегда можно показать заказчику, что работа над проектом идет. Ему не придется месяц трястись и трахать мозг менеджеру, ожидая выполнения самой большой задачи.

Так что, если в коде разбираешься или проект новый - то от сложного к простому, если нет - от простого к сложному.

Оказывается:

При использовании инструкции $count++ увеличение переменной $count выполняется после того, как будет рассчитано выражение с использованием данной переменной. Например, $i =$count++; — переменной $i будет присвоено значение переменной $count до того, как последнее будет увеличено на единицу. Это означает, что машина должна сохранить значение $count, чтобы использовать его в любом выражении с переменной $count. В инструкции же ++$count значение переменной увеличивается на единицу до вычислений, поэтому нет необходимости хранить временное значение (а это менее накладно). Если инструкция $count++ применяется в выражении, где значение переменной не используется (это называется пустым контекстом), то ее можно безопасно преобразовать в преинкрементную инструкцию.

Конечно, фигня там получается, а не оптимизация, но зато в таком коде сразу видна рука мастера

На деле же, нормальные ботописцы забили давно болт на распознавание компом капчи - потому что это слишком бессмысленно когда есть Его Величество "Метод Леммингов".

Суть метода очень простая. Бот заходит на страницу-жертву, выкачивает картинку с капчей - и отправляет на специальный сайт заявку. На сайте сием день и ночь сидят голодные дети из банановых стран, которые любят работать за копейки. Они эту картинку распознают, пишут текст в форму - и через пару минут робот может уже забирать текст капчи. Текст отправляется на сайт - и все :) Вот вам и супер-защита.

Гораздо эффективнее защищаться тем, что может браузер, но не может бот. Например, с выполнением javascript-а насколько я знаю у всех языков реальные проблемы. Конечно, можно пользоваться и браузерами как помошниками в спаме и т.п. - в винде например IE как ком-объект отлично вызывается. Да вот только программист, который это наколбасит будет стоить гораздо больше, чем годы работы голодающих детей банановых стран.

В реальности, распознавание капчи ботами - не проблема. Так что если тебе по-барабану на детей африки - поставь хитрожелтую проверку интерпретации javascript-а и это будет работать гораздо лучше.

$seconds_count = 86400;

Не, я тут не буду писать про переменные и т.п. я буду писать про числа. Возьмем число в примере - слету и не разберешь че это такое вообще... Вот если бы:

$seconds_count = 24*60*60;

Эх, если бы те, кто вычисляет такие числа и пишут как в первом случае знали бы как устроены трансляторы кода, то никогда бы не стали ничего считать. На самом деле, все такие константы вычисляются на стадии формирования промежуточного кода. Одновременно с этим отсекаются недостижимые куски кода и т.п.

Другими словами, если код транслируется один раз, а потом берется уже откешированый, то смысла в этом нет вообще - ну один раз сделает комп вычисление умножения, которое само по себе очень легкое - что с того? Ну а если же нет - и php-код будет каждый раз интерпретироваться без сохранения промежуточных вариантов - то не проще ли врубить eAccelerator? Да и нужна ли такая типа оптимизация в проекте в котором все положили на реальное ускорение через кеширование?

$obj = new Typed;

Вначале мне казалось, что это просто от криворукости программистов и работает также как и массивы, в которых индексы пишутся без кавычек типа $a[index], где автоматом заводится константа с тем же значением и это на удивление работает. Оказалось констант никаких не заводится - а это просто особенность языка.

Оказалось, что такая манера создания классов была описана в мануале по классам и объектом самими разрабочиками php для php4 на php.net.

Вопрос, нафига? В самых распространенных языках программирования везде пишутся скобки после имени класса. IDE от тех же Зендов тоже подсказывает $obj = new Typed(); По-моему, это только запутывает.

P.S. Кстати и в 5-м php та же фигня в описании...

Представим себе проект, который посещает человек 300 в день и у которого внезапно отвалилась база данных. Ну например, место кончилось или еще че-нить. Пользователь, который видит, что страница не загрузилась есстественно попробует ее перезагрузить несколько раз для верности. Ну и каждый раз есстественно письмо админу

Таким образом, пока админ успеет среагировать - его ящик будет переполнен ну или же, что скорее всего, сайт улетит в бан за спам и потребуется много времени чтобы объяснить почтовикам что он не спамер, а просто так получилось. Я имею ввиду, что спам-фильтр будет резать письма с этого сайта, которые идут на мыло админа.

Чтобы дать этой идее хоть какую-нить жизнь, нужно написать специальный анализатор, который будет разбирать ошибки и недопускать повторного отправления одного и того же, что в принципе довольно геморно, потому что написан он будет на php, стало быть если отвалятся некоторые php-шные части (например, отправка писем ), то он все равно не сможет выполнять свою задачу.
Так что отправка писем с ошибками администратору - тупая идея

Такой жестяк часто встретишь, когда пишут код студенты или просто люди торопятся да так что ппц. Нифига не понятно. Запрос написан в стиле write-only. В противовес индусам - нормальные программисты используют определенные правила форматирования кода в запросах. И хоть каждый использует свои, как правило они очень похожи.

Если честно меня бесит, когда запрос формируется налету прямо в параметре функции, поэтому я всегда стараюсь выносить строку запроса в отдельную переменную, если конечно запрос не настолько простейший что там заглючить просто нечему.

$query =  "select articles.title, articles.text, articles.id, articles.user_id, users.name from articles left join users on articles.user_id=users.id where $condition order by id desc limit 5, 10";

$res = mysql_query($query);

Если запрос глючит - делаем принт $query - и смотрим что не так - и не надо ничего выдирать, особенно если ф-я в оболочке принимает 100500 параметров, один из которых длиннющий запрос.

Второе правило - все ключевые слова sql должны быть с большой буквы.

$query =  "SELECT articles.title, articles.text, articles.id, articles.user_id, users.name FROM articles LEFT JOIN users ON articles.user_id=users.id WHERE $condition ORDER BY id DESC LIMIT 5, 10";

$res = mysql_query($query);

Так уже гораздо понятнее - по ключевым словам можно разобраться что и где находится.

Третье правило - выделять отступами и писать на новой строчке логические части запроса.
Четвертое - использовать псевдонимы таблиц, если их больше 2-х. В конечном итоге получается такой запрос:

$query =  "

    SELECT
        A.title,
        A.text,
        A.id,
        A.user_id,
        U.name
    FROM
        articles AS A
    LEFT JOIN
        users AS U
    ON
        A.user_id=U.id
    WHERE
        $condition
    ORDER BY
        id DESC
    LIMIT
        5, 10

";

$res = mysql_query($query);

Некоторые используют конкатенацию в описании запроса, чтобы сделать его меньше, сохранив форматирование - т.е. также как и выше, но скажем 'SELECT '.'A.title' ну и отступы понятное дело также так и у меня, просто что они не в теле запроса. Такой подход делает запрос меньше по размерам и в некотором роде производительнее (т.е. базе пересылать надо меньше), однако форматирование сохраняется только в php коде, но не сохранятеся при выводе и отладке, что неудобно.

Стоит отметить что псевдонимам таблиц стоит давать осмысленные имена. Я часто видел псевдоними t1, t2, t4 - просто номера не дают никакой информации и не помогают с читаемостью таких запросов.

Так-то

<?php
print "Hello World!";
echo "Hello World!";

И то и то выдаст "Hello World!", однако разница между ними все же есть, просто сложно придумать ситуацию, в которой она была бы заметна:

1. print возвращает true/false в зависимости от того, удачен вывод или нет. Я не представляю себе ситуации, в которой она бы вернула false, но наверное есть... echo ничего не возвращает;
2. echo нельзя использовать со скобками, т.е. echo(123) - выдаст ошибку, print(123) - нормально отработает;
3. Понятное дело что из-за п.1 echo работает быстрее чем print. Разница несущественная, но есть и это неплохо знать;
4. В echo можно передать несколько параметров для вывода через запятую (echo 123, 'aaaa', 33 и они выведутся последовательно. В print нет.

Я не уверен, все ли я описал тут, но думаю достаточно чтобы выяснить что они ни разу не синонимы. Если кто знает еще - пишите в коменты - буду рад узнать что-нить новое.

Использование вместо функции is_int регулярного выражения для определения того, является ли $п целым числом, может показаться странным. Однако функция is_int не делает того, что в данном случае требуется. Она только проверяет, типизирована ли переменная $п как строковая или как целочисленная, но не проверяет, является ли значение переменной $п целым числом. Данный нюанс может ввести разработчика в заблуждение, если он использует функцию is_int для проверки данных HTML-форм (среди прочего).

Я как-то не сталкивался с этим раньше и решил проверить. Оказалось действительно:

<?php
var_dump(is_int("56"));
var_dump(is_int(56));

Выдает: bool(false) bool(true) 

Если кто не знает, в смарти используются разделители для того, чтобы обозначить что данный кусок кода все-таки написан на смарти а не просто текст. И хоть в доке по нему явно написано, что разделители дескать можно настроить любые какие только душе угодно - на деле же все используют именно то что там по умолчанию ( фигурные скобки ), ибо все готовое написано именно так, а переписывать готовое ради разделителя не айс ни разу.  Вот и получается что код javascript-а, обрамленный в блок (например function foo() { ... }, да или просто любой блок) шаблонизатор воспринимает как директиву Smarty и пытается его исполнить. И чтобы такого не возникало, придумали специальный костыль - обрамлять куски html, в которых встречаются разделители тегами {literal}тут код{/literal}.

Приятель, для которого код - это что-то из серии магии, воспринял это нормально. Их с версталем не бесило то, что они убили полдня на выполнение простейшей задачи. Но если бы они знали, что оффициально смарти (да и вообще любой шаблонизатор) нужен для того, чтобы разделить логику работы приложения от логики отображения и в куче зомбирующих постов про него написано, что верстальщикам проще редактировать шаблоны, написанные в нем, чем в чистом php, то наверное реакция у них была бы совершенно другая.

Если у нас есть php-ка, которая начинается с xml заголовка, то при включенном short_open_tag - заголовок будет интерпретироваться как php-код. Ну собственно вот для наглядности:

info.php c кодом:

<?xml version="1.0" ?>

[Дальше xml или html]

Выдаст: Parse error: syntax error, unexpected T_STRING in ...info.php on line 1

На относительно больших проектах, написаннх ровноруко, такой баг врятли поймаешь, но если писать скажем самопальную rss-ку без mod_rewrite или скажем XML Sitemap, то вполне.

Насчет же тегов мне всегда казалось, что в тех же шаблонах, сделанных например в стиле Zend_View, гораздо удобнее писать <?=$variable?>, чем <?php echo $variable; ?>, но на мелких доделках и самопальных решениях не все может прокатить, поэтому надо быть осторожными и стараться использовать чужие наработки.

Жесткая табуляция (hard tabs)— это обычные символы табуляции.

Мягкая табуляция (soft tabs) в действительности вообще не является табуляцией; каждый отступ в мягкой табуляции фактически представлен определенным количеством обычных пробелов.

Многие старые программисты почему-то предпочитают мягкую табуляцию. Единственным аргументом у них служит то, что дескать в редакторе можно указать за сколько пробелов по ширине считать таб - и поэтому код в разных редакторах будет выглядеть по-разному. Они заменяют табы определенным числом пробелов - и в итоге код действительно выглядит одинаковым по отступам везде, даже во встроенном в ftp-клиент редакторе или блокноте.

Нет смысла сильно акцентироваться на том, что замена табов пробелами увеличивает вес файлов проекта и что заливать их становится не так круто. Это было актуально раньше при диал-апах, но сейчас не принципиально.

Я бы хотел остановиться на все-таки отступах. Давайте не будем обманываться: любой нормальный программист использует для кодированию ту или иную IDE, ну а редкие случаи хотфиксов таких, что просто влом открывать IDE чтобы поправить тот или иной кусок - просто настолько редкие, что можно даже не упоминать про них. Ни один же нормальный прогер не будет кодить в блокноте. Так вот, фишка IDE-шек в том, что там можно настроить ширину табуляции, а вот ширину пробелов настроить нельзя. Возможность настройки - и есть преимущество, это не недостаток Я например, привык чтобы таб был в 4 пробела, но мне пришел проект, в котором ребята использовали мягкую табуляцию в 2 пробела или в 5 пробелов - в итоге я конечно перенастроюсь, но работать будет реально не удобно, потому что я привык к другому. С другой стороны, проект пришедший с табами - отлично отобразится у меня в том стиле, в котором мне удобно, даже если прогеры, что его писали использовали таб шириной в 1 пробел. С жесткой табуляцией я смогу спокойно внести изменения в такой чужой проект - и когда кто-нибудь другой его откроет - он увидит что все будет в одном стиле.

Подытожив, хочу сказать, что проблема с отображением в разных редакторах и разными отступами на деле является надуманной, поэтому в этом холиваре  оливковая ветвь достается жесткой табуляции. Таб должен быть табом

На деле знание приоритетов не особо нужно, потому что сложные выражения все равно лучше обрамлять скобками, чтобы не запутаться. Но часто бывает что человек даже не знает что спросить (ну или просто хочет сбить цену, спрашивая то, что все по идее должны знать, но так как редко пользуются - то не помнят).

Поэтому, если ищем работу - то вот это надо выучить:

Левая ассоциативность означает, что выражение будет вычисляться слева направо, правая - наоборот. На примере:

<?php
$a = 3 * 3 % 5; // (3 * 3) % 5 = 4
$a = true ? 0: true ? 1 : 2; // (true ? 0 : true) ? 1 : 2 = 2

$a = 1;
$b = 2;
$a = $b += 3; // $a = ($b += 3) -> $a = 5, $b = 5

...AND (`struct`.`regions` = "" OR `struct`.`regions` REGEXP "^a:[0-9]+:\{.*(i:[0-9]+;s:[0-9]+:\"'.$current_region_id.'\"\;).*\}$" OR `struct`.`regions` REGEXP "^a:[0-9]+:\{.*(i:[0-9]+;s:[0-9]+:\"'.ALL_REGIONS_ID.'\"\;).*\}$" OR `struct`.`regions` REGEXP "^a:[0-9]+:\{+(i:[0-9]+;s:[0-9]+:\"0\"\;)*\}$" )...

и не сразу вкурил что это за загадочный REGEXP. Оказалось что это синоним старого доброго RLIKE, ну точнее последний синоним первого так-то

Не буду копипастить - статья лежит тут: http://bolknote.ru/2009/04/04/~2074 советую прочитать всем.

Раскажу я о том, что это может поправить. Так вот, дело в том, что когда IE подгружает страницу по https, в которой есть ссылки на цсски или джээсники по http - ругается, дескать "This page contains both secure and nonsecure items". Такой баг я поймал когда прикручивал WorldPay - там страница ответа подгружается системой и отображается как своя - т.е. ваша страница ответа будет по урлу http://www.worldpay.com/etc.... Ясное дело, что если ссылки в урлах относительные - то css не загрузится и дизайну кабзда поэтому ссылки делаются абсолютными - ну а если они генерятся автоматом - то путь на них будет по http - вот и получаем такой варнинг. Если же пользоваться «Common Internet Scheme Syntax», то все будет окей жаль что я не знал этого пару лет назад

Оказалось, что все можно делать гораздо проще, используя тег <colgroup> и теги <col>, т.е. можно сделать вот так:

<table>
<colgroup>
<col width="500">
<col width="100">
</colgroup>

и все td-ки будут отформатированы в соответствии с этим правилом.

Сам же тег позволяет делать гораздо большее:

Тег <COLGROUP> предназначен для задания ширины и стиля одной или нескольких колонок таблицы. Этот тег позволяет уменьшить код таблицы за счет сокращения повторяющихся параметров, и при наличии этого тега браузер начинает показывать содержимое таблицы, не дожидаясь ее полной загрузки. Тег <COLGROUP> можно использовать в комбинации с тегом <COL>, который определяет характеристики одной или нескольких колонок.Обычно закрывающий тег не требуется, но если <COLGROUP> выступает как контейнер для элементов <COL>, тогда следует добавить тег </COLGROUP> в конце группы.Разница между свойствами тегов <COLGROUP> и < COL> не очень велика и состоит в следующем. <COLGROUP> позволяет объединять колонки в определенные группы, также при добавлении параметра rules="groups" к тегу <TABLE> браузер будет рисовать линию только между колонками, созданными с помощью <COLGROUP>. В остальных случаях поведение колонок назначенных через элементы <COLGROUP> и <COL> идентично.

Кстати, уже раза 3-4 лезла верстка из-за того, что при добавлении/удалении новой td-ки забывал добавить новый col... такой вот потенциальный баг при использовании...

Тег <NOBR> (NO BReak line) запрещает перевод строки. Бывают случаи, когда возникает надобность в операции противоположного назначения – запретить перевод строки. Текст, заключенный между тэгами <NOBR> и </NOBR>, будет гарантированно располагаться в одной строке без переноса на другую. Длинная строка не уместится на экране, и для ее просмотра придется использовать горизонтальную полосу прокрутки. Закрывающий тег обязателен

Атрибутов нет, хотя какие-тут могуть быть аттрибуты

У многих программистов (как правило, начинающих) в голове почему-то строится странное соответствие: формы = POST. Понятное дело, форма авторизации - постом, ибо показывать кому-то логин-пароль в урле - брррр, контактная форма - тоже пост и т.п.

Но это потому что POST:

Применяется для передачи пользовательских данных заданному ресурсу. (c) Википедия (да-да, надо было со спецификации, но влом)

Т.е. POST создан для того, чтобы отправлять данные на сайт. А вот GET, чтобы получать данные с сайта:

Используется для запроса содержимого указанного ресурса. С помощью метода GET можно также начать какой-либо процесс. В этом случае в тело ответного сообщения следует включить информацию о ходе выполнения процесса. (c) Википедия

Поиск - это получение данных (посмотрите тру поисковики - они это знают ), так что делать его постом - просто не по стандартам.

Хотя на деле все и так ложат болт на эти стандарты абы работало и я бы не стал писать об этом. И фигня даже то, что человек никогда не сможет дать товарищу ссылку на результаты поиска (потому что постом урл не изменится) - мало ли такого чтоли. Фиг с ним.

Жопа начинается, когда появляется постраничный вывод результатов поиска.

Дело в том, что параметры поиска (которых нет в урле) надо где-то помнить. И один из костылей - это чтобы при нажатии на номер страницы форма сабмитилась снова (со всеми параметрами) + скрытый инпут с номером страницы. Ежу ясно, что открыть страницу в новом окне просто не получится никак.

Второй вариант костыля в том, чтобы помнить в сессии параметры поиска, а номер страницы уже добавлять в урл. Тут появляется жопа #2. Если пользователь открыл страницу в новой вкладке и на ней зашел на вторую страницу поиска (т.е. сессия та же, но открыты 2 страницы поиска), то одна из страниц будет перекрывать вторую. На это тоже ставится костыль и т.д.

В целом, поиск постом - это не по стандартом и провоцирует множество костылей. Однако есть одна ситуация, когда без этого просто никак: а именно когда длина url получается больше допустимой (в ie 2048 символов, в остальных побольше).