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

Вот, например, одна из схем. 
При указании в урл параметра `&test=flag1,flag2,flag3` формируется кука с именем test и содержимым `flag1,flag2,flag3`. После формирования куки происходит переход по адресу, с вычищеным от этого параметра значением URI.
При наличии этой куки, программист может, например, использовать функцию

чтобы менять логику приложения. Как написать такую функцию - вопрос достаточно тривиальный...

На моем прошлом месте работы (крупный известный сайт в РУ сегменте) мы делали примерно как ты сказал (с использованием get-параметров, но без кук) - в Url подставлялся некий ключ, далее имелось функция, проверяющая "офисный ли это ИПшник, либо userId из списка IDшников разработчиков (на случай, если из дома)" и тогда делаем, что нам нужно. В коде это выглядело примерно так:



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


либо, через систему таргетингов (удобно для тестеров, когда не все их пользователи - редактора):


А в админке таргетингов нужно создать таргетинг с именем myTestTargeting, например по тому же перечню IDшников, либо другому списку идентификаторов.

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

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

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

По в любом случае проверять что-то только по куке - точно не секурно.

Aliance, а что за проблемы с куками? Ну пусть я отлаживал сервис, проект заглох и я  благополучно забыл его на чужом сайте. Это само по себе косяк, оставить отладочные вставки, ну да ладно... Если плагин не содержит в себе устройство для взлома сайта - его внезапное появление для пытливого пользователя, вроде как, безопасно. 

Фильтр по IP несколько затрудняет демонстрацию фичи заказчику. Придется сначала выяснять этот самый IP... Хотя, в принципе, правильно.

Я говорил о подобном функционале в целом, а не в частности - не разделяя на то, несет ли он в себе опасность или нет. И, кстати, что подразумевается под плагином? JS что ли, мы же в треде по PHP =)

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


для этого придумали стейджинговые сервера 

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

Насчет плагинов
Задачки возникают разные и на разных платформах, разных CMS. Где-то что-то добавить/исправить - систему слежения за банерами, поиск по сайту, какие-то формы-подписки. Название  "плагин", imho, вполне подходит для задачи с неопределенным объемом работы    
Тем более, что такая задачка, таким образом отлаживаемая, идеологически плагином и является - удалил флажок в куках - вот и нет его. А после отладки тот флаг можно заменить на флажок в конфигурации...
Все дело в системе определений. 

Если вы пишите свое, и подключаете модуль (плагин в рамках РНР понятие резиновое), то вроде бы как рационально, чтобы модуль мог иметь режим активен/неактивен или отображается/не отображается. А что мешает добавить еще и режим "отладка"? Ну ладно бы они написаны вами "капитально и навека", но ведь и старое зачастую обновляется, и тоже возникает потребность в отладке.
Естественно, что режим отладки, в этом случае, доступен в режиме администрирования - тут и конфигурация, и опции, и "опознавание" не по временным кукам, а по входу администратора. А для пользователя этот режим тоже самое что и неактивен.   

Чтобы не растекаться уж совсем мыслию по древу, вот пример для "посмотреть".


whatisnot, меня интересует сам процесс монтажа уже "в принципе готового" модуля в работающую систему. Модуль еще требуется доработать напильником по месту, однако остальные пользователи системы не должны сильно пострадать. В идеальном случае - они не должны ощутить ничего, до момента окончания отладки. Этот класс и будет тем скотчем, на который можно "наживить" тот самый модуль и избежать, потенциально, отрицательных последствий для обычных пользователей.

Класс статический, так как одно из назначений его - гарантировать текстово-единообразный след в исходниках. Можно просто тупо поискать `DBG::` по файлам и обнаружить все "точки склейки" модуля и системы. Собственно монтаж будет начинаться с подключения класса во все возможные точки входа системы, довольно удобно - добавить его в auto_prepend_file. Окончательная вклейка модуля в систему заключается в выкидывании упоминания DBG из "точек склейки" и чистка препенда.

Это сообщение отредактировал(а) ksnk - 12.2.2015, 15:49

Хотите скачать, что без некоего индивидуального флага у модуля, без кук и припарок preg_match невозможно "отключить" пользователя? Ну это же не так. Для упрощения:

У меня в системе три ресурса - А, B, C. Могу ли я через конфигурацию отключить вывод любого из этого ресурсов пользователю, а для себя сделать доступным? Могу.
Пусть и ресурсы имеют подключаемые модули. Могу ли я и их через конфигурацию также сделать недоступными для пользователя? Могу.
Если я включаю режим отладки ресурсу/модулю, вхожу как администратор и в одном браузере открыт и раздел управления, и страница ресурса, то мне и кук не требуется, меня и сессия "опознает".

Я не говорю, что вы поступаете не так, каждый волен думать так, как он думает. Просто я исхожу из того, что если уж делать систему, то лучше ее делать кофигурируемой не только для случаев "А показывать в Б", но и показывать ли А и кому. 

whatisnot, Мы говорим о разных вещах. Тред назван ` Тестирование новых фич сайта "на лету"`. Вероятно, нужно было назвать "монтаж".
К примеру, на некий сайт требуется поставить поиск. По каким-то причинам (самодельный CMS, неподходящий набор плагинов...) разумной системы поиска у него нет. 
Монтируемый модуль поиска имеет "точки вклейки" в систему
-- шаблон вывода header'а - туда нужно вставить вывод формы поиска,  скриптовые и стилевые изменения.
-- вывод страницы с результатами поиска - отдельные страницы в дизайне сайта
-- настройка плагина в админке  (очистка результатов, переиндексация, параметры ets...)

Изменений дофига и уследить за корректным и сразу 100% работающим кодом достаточно сложно. Ломать внешний вид сайта и обижать клиенов на время отладки нельзя.

Класс расчитан именно на это время, от начала монтажа, до окончания отладки. После этого он удаляется с сервера за ненадобностью.

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

Видимо, да. В моей практике регулярно повляются самодельные и native-php сайты, и `модуль`или `плагин` для них - достаточно резиновое понятие. 

Если ваш "самодельный" не имел модуля поиска, то как он работал без него, ничего в нем "не ломалось"? Думаю нет. Добавили модуль, кторый доступен только вам, что-то "поломалось", кто это видит, вы или все? Видимо только вы. А что видит пользователь? Прежнее. В чем беда, я не понимаю.
Я так понимаю, что это и есть ваш аргумент в пользу кук с классами. Но до меня он не доходит, ибо по логике вещей такого просто быть не может. А если моудуль не изолированный, как тот же поиск, и так или иначе затрагивает русуры страницы, если это можно сделать через конфигурацию, то и поставить всю страницу в режим отладки нет проблем - в этом режиме она будет опять таки доступна только вам. И по большому счету, как это будет сделано роли не играет, вопрос только в гибкости и удобстве.

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

ksnk, у вас есть уже кука (или другой подходящий идентификатор) - сессия.
что касается выковыривания отладки, я в целом согласен с whatisnot. пусть ваша отладка живет постоянно, вы только меняете политику применения конкретного функционала ("модуля") - переводите его из тестирования в продакшн через конфигурацию.

baldina, Ну вообрази, что включаемый модуль содержит синтаксически некорректный код. Ну вот случайно по ftp непдокачался код... Сломается ли сайт, если такой модуль попытаться вставить в систему? А вот если все места, в которых упоминается модуль, оклеить "скотчем", то простой посетитель будет иметь работающую версию сайта, не смотря ни на что. 

Если для выключения модуля в каждую его составляющие требуются вставки, то это не модуль, а как раз "нечто скленное скотчем". 

Это сообщение отредактировал(а) whatisnot - 11.2.2015, 13:59

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


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

Я тут пример выдавал... Форма поиска. Она должна быть видна на всех, в том числе и на главной, страницах. Она должна быть видна (после отладки и сдачи) для всех, в том числе и незарегистрированных пользователей. Тоесть, на главной у нас нет (в принципе) ни сессии, ни юзера с правами. Без дополнительного механизма его не отладить. Никакими галочками в админке.
Механизм - универсльный. Он позволяет "клеить" не только в благоустроенных условиях современных CMS, но и вообще в любых, способных поддерживать (php5.2++)-жизнь   

>Тоесть, на главной у нас нет (в принципе) ни сессии, ни юзера с правами.

Очень странно. Это по чьим итересно принципам главная обделена сессией?

>Без дополнительного механизма его не отладить. Никакими галочками в админке. 

Это далеко не так.

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


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

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


Это сообщение отредактировал(а) baldina - 11.2.2015, 17:26

baldina, Сессия стартует ВСЕГДА при первом же визите юзера на сайт? Всегда и на всех сайтах? И эти люди будут учить меня программировать?   

если сессия нужна при первом же визите юзера на сайт, отчего бы ей не стартовать?
если неизвестно, нужна ли сессия, отчего бы ей не стартовать? 
какие вообще ограничения по старту сессии, и откуда?

Уже дошло до абсурда. )

Музыкант оперирует 12-ю нотами, это его инструменты, и при этом одни создали бессмертную классику, другие поразительную по чувствам современную музыку. А что есть чувства? Это пропустить через себя виденное, выразив его через музыку.

У художника краски, и одними и теми же цветами рождаются разные шедевры, от реализма до абстракционизма. Что они отражают? То же самое, мир нас окружающий взглядом художника.
Программирование тоже творчество, в первую очередь, конкретный код, это во вторую очередь. Отличие программиста от музыканта и художника лишь в инструментах, и способе выражения своих чувств. Что музыканту, что художнику, что программисту важно понимать, чувствовать инструменты, без этого не будет ни Лебединого озера, ни улыбки Джоконды, ни Mac OS. Будет нечто серое, посредственное.

Я это к тому, что все вами сказанное в качестве «аргументов в пользу за», и просто высказываний, и которые, конечно же, касаются программирования, могу переложить на нечто из мира реального, но описывающее именно вашу ситуацию. Ведь ПО, это тоже нечто из реального мира, например, организовывая диалог с пользователем, вы создадите ровной такой, какой будет базироваться на вашем понимании человека, его психологии. Ну а самым ярким примером жизни описанной программистом можно назвать корзину интернет магазина. Вот уж где часто можно видеть – тот, кто ее написал, либо ни разу не был в реальном магазине, либо не задумывался о назначении ее прототипа – реальной тележки на четырех колесах.
 
Теперь абстрагируемся от классов, сессий и прочего, и обрисуем ситуацию вашу, но иными категориями.

>Ну вообрази, что включаемый модуль содержит синтаксически некорректный код. Ну вот случайно по ftp непдокачался код...

Я это сравню со следующим:

На завод N приходит человек, минуя отдел кадров прямым ходом в цех. Мастер цеха – «ты где шляешься?», подзатыльник, к станку его и дает норму, не интересуясь вопросом, сможет ли вообще он выполнить эту работу. Объяснение этого горе работяги – «извините, но я дома штаны забыл», никого не интересуют.

Ситуация на заводе N изменилась в лучшую строну, по мнению руководства.

>А вот если все места, в которых упоминается модуль, оклеить "скотчем"

Для решения проблемы поступили просто и сердито – к работяге приставил наставника, а чтобы штаны не терял к его штанам приставили смотрителя.

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

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

Длинный монолог, но как иначе. )


Это сообщение отредактировал(а) whatisnot - 11.2.2015, 20:02

baldina, Каким еще способом, кроме сессии, я могу сказать приложению, что вот этот вот модуль на самом деле включен? 
Кстати, для того приложения, в котором мне пришлось делать поиск, сессия стартовала только при заполнении форм обратной связи. Да и там, по сути, была не очень то нужна... 

А по сути есть что сказать?

Резюмирую, для простоты понимания.
Я предлагаю использовать отдельный инструмент, который по моим представлениям, позволяет достаточно безопасно для посетителей, заниматься отладкой достаточно сложного дополнительного функционала, прямо на сайте, без его отключения.  Безопасность, в этом случае, означает, что посетители всегда имеют рабочую версию сайта. 
Для использования инструмента нужно придерживатьс несложной дисциплины и следить за правильным синтаксисом в "местах вклейки".

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

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


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


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

Да. Я в нескольких местах это, вроде, уже говорил. Вероятно, недостаточно явно. Область применения - доделка неизвестно кем, неизвестно когда и неизвестно на чем написанных проектов. "Неизвестно" - в рамках моей способности понять код и способности кода работать на php5.2++.
С такими условиями, аппеляции к галочкам в админке и правам на модули несколько необоснованы. Что, видимо и вызвало мой нездоровый смех   

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

Сказать по сути - а что? Я вам и сказал как раз по сути, ибо случай с FTP, это уму не постижимо так же, как и с абсурдом мной описанным. Это что получается, составляющие вашего модуля грузятся на сервер по собственной инициативе и мало того, еще и не дождавшись загрузки окончательной, самовольно подключаются и начинают работать? Как еще можно понять это вами написанное?

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

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

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


Это сообщение отредактировал(а) whatisnot - 12.2.2015, 14:40

whatisnot, Искренне завидую человеку, который не в состоянии понять о чем я говорю. Серьезно   Я, вероятно, мечтал бы жить в таких тепличных условиях.

А в моей реальности встречается вот, например, такое: 
Проект, в которой 2/3 контента выглядят как в меру разумно сверстанный html, в начале которого стоит <? include header.php ?>, а в конце <? include footer.php ?> и хидер и футер - такой же в меру разумно сверстанный html. Остальная треть - какие-то формы, сверстанные с тем же минимализмом. Мне, почему то, кажется, что это не такие уж и редковстречающиеся условия...

Это уже не абсурд, это уже кошмар, ей богу. В чем может ограничение в стандартном - подключение шапки и подвала, а в середине основной контект, чего то там? Чего в этих формах такого, что не позволяет управлять подключением по управляющему им скрипту?

То что вы привели ни как не описывает проблемы, да и если она вообще.

Может быть, само отсутсвие управляющего скрипта?

Это уже не проблемы отладки, это уже безголовость разработчика. Вот потому что у вас все "клеится скотчем", нет ведомого и управление модулем не не нему, такой бардак может и возможен.

Даже слов не нахожу, чтобы такой абсурд комментировать. )

whatisnot, Чтобы не съезжать на личности - тот пример - достаточно долго живущий сайт, совершенно устраивающий его хозяина. За исключеньем пустяка - ему нужен был поиск. 
Администрировался Дримвейвером, еще от макромедии. Очень вероятно, что сам хозяин его и сделал. 

  

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

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

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