Не лично, я от D7 в восторге .. но да в него вникнуть сложно

он по UF_ подцепит ещё одну таблицу

$sectionsList = \Bitrix\Iblock\SectionTable::getList( array( 'select'=>array("ID","IBLOCK_ID","NAME","UF_GROUP_NAME"), 'filter'=>array("ID"=>$sections), 'group' => array('UF_GROUP_NAME') ) );

вот так не работает

почитай историю - про тот же nescape navigator например (продукт другого уровня, но больше и сильнее гораздо команда была, и проблемы обратной совместимости не было)

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

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

ой ли? не нужна программистам или не нужна бизнесу и хуевой туче сайтов?

которые как то обновлять надо

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

есть как минимум одна цмс - которая решила что обратной совместимости на прошлое ядро если делать, будет достаточно, если ядро менять каждые два года вроде как и 4 года гарантии, и апи можно внутри менять, красота на деле 2 года получается, стабильно раз в 2 года отваливается тонна функционала вы слышили что-нибудь про друпал же ведь, да? )

и отдельно новое ядро, написаное с нуля

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

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

а зачем она? кому нужна? сделайте конвертацию магазина - и поделам.

вроде все разрабы, никого из мира розовых пони нет..

а зачем она? кому нужна? сделайте конвертацию магазина - и поделам.

смешно шутите

$sectionsList = \Bitrix\Iblock\SectionTable::getList( array( 'select'=>array("ID","IBLOCK_ID","NAME","UF_GROUP_NAME"), 'filter'=>array("ID"=>$sections), 'group' => array('UF_GROUP_NAME') ) );

угу, посмотрел не задана связь в ORM

Не лично, я от D7 в восторге .. но да в него вникнуть сложно

та оно хорошее, только СКОЛЬКО МОЖНО КОРМИТЬ ОБЕЩАНИЯМИ?

а зачем она? кому нужна? сделайте конвертацию магазина - и поделам.

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

угу, посмотрел не задана связь в ORM

Спасибо, буду сторое использовать API тогда

http://joxi.ru/zAN4Lv8tW3Wnm9

Можно UF вытянуть через $USER_FIELD_MANAGER

Спасибо, буду сторое использовать API тогда

if($module=='iblock') return oldCore без вариантов :) в стикеры блин

не с точки зрения D7 новый функционал проще на нём, старый лучше оставить как есть, пока не возникнет реального желания перевести его на d7

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

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

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

безопасность, обещание по старым багам, новые законы

безопасность, обещание по старым багам, новые законы

а кто запрещает обновлять старое ядро?

закрывать баги по нему?

и наращивать функционал? или хотябы поддерживать?

и наращивать функционал? или хотябы поддерживать?

зачем наращивать? если оно старое? только поддержка и безопасность.

если наращивать функционал не надо, тогда тем более делать два разных продукта

два независимых и не перемешанных ядра

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

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

А потом обновимся и всё? Или полгода разрабатывать новый магазин перед обновлением, и проблемы с БД по пути подхватим)

Тут да, 2 продукта по сути

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

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

а вы с реальными проектами то работаете? Которые на поддержке по пять семь лет?

проблема в том - что тут нет однозначного правильного решения..

а вы с реальными проектами то работаете? Которые на поддержке по пять семь лет?

Уххх господа.... Да работаю я с ними. Что это меняет?

в чем проблема оставить старый продукт как есть?

магазин/проект/портал от этого не перестанет работать!

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

хочешь новую супер-киллер фичу - пили на новом ядре.

Вы предлагаете 10к партнеров пересадить одномоментно на новое API не развивая старое

оригинал чо

Тут да, 2 продукта по сути

Я про сайты, а не про ядра Битрикс Клиент: ой, а Битрикс сейчас же кассы умеет, там какая-то новая версия языка, прирост в 2 раза, давайте обновимся! Разраб: Знаете - Вам надо писать новый сайт под новове ядро.

Вы предлагаете 10к партнеров пересадить одномоментно на новое API не развивая старое

так а старое и не развивается. Вы работаете с реальными проектами?

Осмелюсь заявить, что ВЕСЬ, абсолютно ВЕСЬ новый функционал пишеться на D7

хочешь новую супер-киллер фичу - пили на новом ядре.

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

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

я не понимаю этого

вы боитесь не освоить новое ядро?

где тут проблема разработчика?

так а старое и не развивается. Вы работаете с реальными проектами?

В старом API кстати добавляют в том числе и поддержку новых фич) По сути ИМХО битриксу надо все переделывать на новое ядро, а старые вызовы типа CIBlockElement делать просто прослойкой для вызова методов D7

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

В старом API кстати добавляют в том числе и поддержку новых фич) По сути ИМХО битриксу надо все переделывать на новое ядро, а старые вызовы типа CIBlockElement делать просто прослойкой для вызова методов D7

по этому пути они и пошли

я не понимаю этого

Вам понравится когда Вам за одно и тоже 2 раза платить надо?

Так, посоны, такой вопрос. Есть два сайта на одной лицензии, но на разных хостингах. Есть ли способ их объединить без геморроя?

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

если ему это важно - он на это пойдет. если он засомневается в Вас - пойдет спросит у других, которые скажут то же самое.

Где тут трудность?

хех

объединение это ппц

где тут проблема разработчика?

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

а если урлы используют id секций или элементов это еще один писец

если ему это важно - он на это пойдет. если он засомневается в Вас - пойдет спросит у других, которые скажут то же самое.

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

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

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

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

минутку - машину он купил вчера (смутное время условного переезда)

минутку - машину он купил вчера (смутное время условного переезда)

если огласить заранее о таком преходе - таких ситуаций не будет

ERROR: S client not available

это уже вопрос организации

но Вы снова увиливаете

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

да где я увиливаю, я говорю что такое бизнес решение - не работает

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

даже пусть протестировали - и оглашают - через год с 23 февраля не поддерживаем ядро - вилка завтра не поддерживаем ядро - снова вилка

я говорю что для разраба проблем нет, проблема для бизнеса

в начале сказал )

Клиентов не принимаем на новом ядре, а на старом делайте. Вот так :D

разраб завтра может на симфони перейти, или лаварель, или в джумлю удариться нет никаких проблем для разраба )

если бы такое случилось - яб поддержкой старого занялся ) это же такой пласт клиентов будет ;)

Разраб может и на старом делать, в этом и дело.

и итог? делаем два продукта - новое не стреляет маркетинг однако)

хотябы потому, что он неизбежно будет сырой

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

поменять дизайн != переписать магазин

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

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

а вот когда навернется обмен с 1с из за обновлений, жопу то разработчикам точно порвут

точнее делается, выправляются нюансы, налаживаются обмены, переделываются неудачные места

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

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

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

кому верить?

один вопрос, не холивара ради, точнее два 1. какой самый продолжительный проект у вас на поддержке 2. почему они не переписались полностью?

среднестатистический магазин через 2 года вообще перестает существовать и правок не вносит ни когда. Может каждый 3 вносит правки. А за 7 лет в портфолио 75% уже убитых проектов.

один вопрос, не холивара ради, точнее два 1. какой самый продолжительный проект у вас на поддержке 2. почему они не переписались полностью?

3 года 2 раза почти все переделали с новым дизайном.

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

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

3 года. бюджета не было

среднестатистический магазин через 2 года вообще перестает существовать и правок не вносит ни когда. Может каждый 3 вносит правки. А за 7 лет в портфолио 75% уже убитых проектов.

вот это правильно, я тоже вижу такое.

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

<sarcasm mode=off/>

3 года 2 раза почти все переделали с новым дизайном.

это малый срок, честно один более 5 лет, иногда доделываются - переезд без www на www вылилось в 2 месяца, без доделок каких либо, ибо китайцы есть проект который я делал около 5 лет назад, ядро там явно еще то, это даже после редизайнов видно, как минимум два подрядчика сменились которые хотели чтото там переделать глобально, ниасилили, причем речь только о внешке, я заю сколько там подставы будет если у них получится и придется интегрироваться с внутренними системами )

один вопрос, не холивара ради, точнее два 1. какой самый продолжительный проект у вас на поддержке 2. почему они не переписались полностью?

3 года с хвостиком, и да он перепилен полностью включая админку и немного ядро