Так главные модули все равно надо писать заново. На фоне этой задачи апгрейд сайта с D5 на D8.x - это один из самых малых вопросов. Зато именно при апгрейде и последующем тестировании результатов будет прекрасно видно, что нужно править или переписывать заново, а что можно оставить старым.
У вас стоит задача апгрейда своими силами?
Просто перенос контента это правда не самое сложное в переходе на версию выше
Все дело в тех самописных модулях - это наполнение страниц специфическим сервисом и backend, ради которого сайт и существует в настоящее время, по сути дела.
Самое надежное: работать с оригинальными названиями.
Но если без перевода никак, то два самых простых пути:
1. При ограниченном наборе названий добавить свою таблицу транслитерации. При этом сразу же там предусмотреть возможность склонения по родам, как это принято в "великом и могучем". Так же, если предполагается ручной ввод названий, такая таблица позволит предусмотреть самые характерные ачепятки (Frod вместо Ford, Aple -> Apple, Phillips -> Philips и т.д.)
Я еще более крутой некрофил, чем автор, но хочу полностью вылечиться
Имеем: D5 на PHP 5.2.17 + MySQL 5.6 + Debian 7.
Хочу перейти на D8 + PHP ... + MySQL 5.6 (5.7) + Debian 9
Есть ли какой-то roadmap совместимости версий всего этого комплекса? Что бы я мог понять что и в какой последовательности обновлять?
Ок.
Сделал тестовый фильтр, показывающий только то, что старее текущего времени на 2160 часов. Не путать с 3-мя месяцами / 90 днями / 90 сутками и т.д. - это фильтр делает именно так, как я пишу.
Работает почему-то.
Толку с тестового скрипта, который не будет вызываться? Тут больше похоже на то, что body ноды из базы не считывается. Или считывается, но парсер PHP не выполняется.
CCK не подходит, так как может ограничиваться доступ к любым абзацам внутри текста.
Темизация шаблона? А можете краткий примерчик накидать?
Я вот пока думаю о своей сборке ноды "на лету" из внешней таблицы. Но тогда надо к ней (таблице) редактор человеческий привязывать и т.д...
2gumk:
проблема в том, что это перестает работать как только у ноды появляется более одного tid. Автору вопроса сейчас это неактуально, а завтра станет актуально.
Подскажите лучше, если например тизер и в нем текст доступен всем.
а полная нода закрыта от гостей. как закрыть весь контект от поисковиков... или некоторую... дабы контент не вылез за пределы сайта.
Посетители и зарегистрированные пользователи это разные понятия
зарегеные получаются из посетителей.
Если уж так хочется шифровки, но надо как-то заманивать посетителей через поисковики, то лучше всего иметь открытую и закрытую инфу.
а зачем закрывать содержимое от гостей, но делать его доступным через поисковую систему?
Ну, на это есть масса причин. ))) Цитирование поисковиками всегда хорошо, независимо от того, закрыта информация или открыта.
Алес! Секрет полишинеля, прям.
"Ты ко мне не заходи - мне посетители не нужны! Ты к гуглю заходи - он расскажет тебе все, что я знаю"
Информация должна быть или закрыта или открыта.
Явно API не читали
Темизировання картинка возвращается из этой функции: theme('imagecache', 'block_avatar (название блока imagecache, определяющий размер картинки)', внутренний_путь_к_исходной_картинке, 'caption при наведении курсора на картинку', 'альтернативный текст для заблокированной картинки')
Drupal 6.19 и PHP-7
Посмотрим
Drupal 6.19 и PHP-7
Так главные модули все равно надо писать заново. На фоне этой задачи апгрейд сайта с D5 на D8.x - это один из самых малых вопросов. Зато именно при апгрейде и последующем тестировании результатов будет прекрасно видно, что нужно править или переписывать заново, а что можно оставить старым.
Drupal 6.19 и PHP-7
Все дело в тех самописных модулях - это наполнение страниц специфическим сервисом и backend, ради которого сайт и существует в настоящее время, по сути дела.
Обратный Translate (из EN в RU)
Самое надежное: работать с оригинальными названиями.
Но если без перевода никак, то два самых простых пути:
1. При ограниченном наборе названий добавить свою таблицу транслитерации. При этом сразу же там предусмотреть возможность склонения по родам, как это принято в "великом и могучем". Так же, если предполагается ручной ввод названий, такая таблица позволит предусмотреть самые характерные ачепятки (Frod вместо Ford, Aple -> Apple, Phillips -> Philips и т.д.)
Drupal 6.19 и PHP-7
Подойдет любой D6.x?
Drupal 6.19 и PHP-7
Я еще более крутой некрофил, чем автор, но хочу полностью вылечиться
Имеем: D5 на PHP 5.2.17 + MySQL 5.6 + Debian 7.
Хочу перейти на D8 + PHP ... + MySQL 5.6 (5.7) + Debian 9
Есть ли какой-то roadmap совместимости версий всего этого комплекса? Что бы я мог понять что и в какой последовательности обновлять?
Хитрый фильтр по дате [решено]
Ок.
Сделал тестовый фильтр, показывающий только то, что старее текущего времени на 2160 часов. Не путать с 3-мя месяцами / 90 днями / 90 сутками и т.д. - это фильтр делает именно так, как я пишу.
Работает почему-то.
D5 не вызывает PHP скрипты
Толку с тестового скрипта, который не будет вызываться? Тут больше похоже на то, что body ноды из базы не считывается. Или считывается, но парсер PHP не выполняется.
D5 не вызывает PHP скрипты
Да. Забыл про PHP сказать
У меня стоит 5.2.17 в режиме FastCGI
Область видимости переменных?
Вопрос с записью в эту переменную таки снят - костыли кривоваты были
Но глобальный вопрос по ограничениям области видимости переменных остался.
Как сделать разграничение прав доступа к части контента ноды?
CCK не подходит, так как может ограничиваться доступ к любым абзацам внутри текста.
Темизация шаблона? А можете краткий примерчик накидать?
Я вот пока думаю о своей сборке ноды "на лету" из внешней таблицы. Но тогда надо к ней (таблице) редактор человеческий привязывать и т.д...
Как сделать разграничение прав доступа к части контента ноды?
Ну не всем же флудить в комментах. По сути сказать есть что?
запрос sql
а черновик и не выведет ничего. на то он и черновик
запрос sql
Нормально
запрос sql
2gumk:
проблема в том, что это перестает работать как только у ноды появляется более одного tid. Автору вопроса сейчас это неактуально, а завтра станет актуально.
запрос sql
Так оно и есть
Сам понял позже. Надо первым запросом отбирать tid, затем во втором запросе отбирать ноды с данным tid и указанием limit 0, 1.
запрос sql
FROM(
SELECT
модуль node доступ к содержанию сайта...
модуль node доступ к содержанию сайта...
зарегеные получаются из посетителей.
Если уж так хочется шифровки, но надо как-то заманивать посетителей через поисковики, то лучше всего иметь открытую и закрытую инфу.
модуль node доступ к содержанию сайта...
Алес! Секрет полишинеля, прям.
"Ты ко мне не заходи - мне посетители не нужны! Ты к гуглю заходи - он расскажет тебе все, что я знаю"
Информация должна быть или закрыта или открыта.
модуль node доступ к содержанию сайта...
а зачем закрывать содержимое от гостей, но делать его доступным через поисковую систему?
Сообщение при создании ноды [Решено]
Таки да. Так, глядишь, у меня скоро на голове и волос не останется.
+1
Сообщение при создании ноды [Решено]
если мессаг надо выводить после создания ноды, то обрабатывайте не $op = insert, а $op = submit.
Переназначение комментария [РЕШЕНО]
comment.module
function comment_links()
Достать image cache картинку из $view [РЕШЕНО]
Явно API не читали
Темизировання картинка возвращается из этой функции:
theme('imagecache', 'block_avatar (название блока imagecache, определяющий размер картинки)', внутренний_путь_к_исходной_картинке, 'caption при наведении курсора на картинку', 'альтернативный текст для заблокированной картинки')