"Составная часть товара" - именно его часть, но она может быть одинаковой в некоторых "товарах". Логическая часть. Карточка "товара" должна взять 3-4 переменных из карточки более подробного описания важной части этого "товара" - "составной части товара".
Поэтому "составных частей" всего 300 штук и в них куча своих Custom Fields (для описания более подробно этой важной части каждого "товара"), а самих "товаров" в 10 раз больше - 3000 штук.
Всё было бы легко, если не надобность выводить большой список "товаров", где пользователь должен видеть 3-4 переменных (Custom Post Fields) из "составных частей товара".
п.с.: если у меня уже крыша едет от этих "товаров", я не представляю, как вы сможете разобраться... :D Но очень приятно, что кто-то пытается вникнуть в суть моей проблемы, спасибо. ;)
SeVlad: Т.е. дублируются в обоих кастомных типах? В стандартном случае - их надо заполнять и там и там? Я правильно понял? Если так - вот тут как мне кацца и ошибка в проектировании.
Вот я и не хотел бы дублировать, а иметь эти поля только в "составных частях товаров", но выводить их (использовать) и на страницах с "товарами".
Загвоздка в том, что надо их выводить не только на самих страницах товаров (single page), но и на страницах с большим списком "товаров" (archive page и подобное). Здесь я упираюсь в слишком большую нагрузку на сервер (куча query из БД).
SeVlad: А что представляют собой эти 3-4 метаполя (ака Custom Post Fields)? Какой содержимое?
Данные с цифрами. Некие Integers, которые надо будет не раз менять. Хотелось бы не менять их ручками по всему сайту, а только в Custom Post Types "составная часть товара", где они уникальны для каждого CPT.
Pavel_: Че мелочитесь-то... Да запихайте всё в h1 - потом нам расскажите... ))
Что за глупое сравнение H1 и DIV?
Pavel_: Для асобо одарённых поясню ::: после тега <p> - на нормальных сайтах идет "контент". А "контент" на странице - априори самое главное!
Бред полный.
<p> лишь указывает, что это -- параграф, а не "самый важный контент".
Открою вам секрет: если хотите указать на своём сайте где именно главный контент находится, откройте для себя role="main" (а для остальных частей сайта другие role) и <article>.
ivan-lev: Делаем таблицу старыйадрес-новыйадрес.. индекс по старому адресу (если адреса сильно длинные - можно хэш какой-нибудь использовать)
в корневом index.php (ЧПУ ведь наверняка используется) подключаем файл, который делает 1 доп запрос к базе на предмет наличия запрошенного URL в таблице редиректов. Если есть - редиректит.. Если нет - возвращает выполнение на основной сайт.
Поиск по индексу в 30к операция не такая уж ресурсоёмкая.
Да, и так можно, наверное.
Но лучше делать структуру нового сайта похожей, чтобы легко было использовать regexp в редиректах.
И это должно быть легко, если движок самописный.
Но, судя по озвученному ТС, там вряд ли самопис, а программер - новичок.
SeVlad, нет-нет.
"Составная часть товара" - именно его часть, но она может быть одинаковой в некоторых "товарах". Логическая часть. Карточка "товара" должна взять 3-4 переменных из карточки более подробного описания важной части этого "товара" - "составной части товара".
Поэтому "составных частей" всего 300 штук и в них куча своих Custom Fields (для описания более подробно этой важной части каждого "товара"), а самих "товаров" в 10 раз больше - 3000 штук.
Всё было бы легко, если не надобность выводить большой список "товаров", где пользователь должен видеть 3-4 переменных (Custom Post Fields) из "составных частей товара".
п.с.: если у меня уже крыша едет от этих "товаров", я не представляю, как вы сможете разобраться... :D Но очень приятно, что кто-то пытается вникнуть в суть моей проблемы, спасибо. ;)
Т.е. дублируются в обоих кастомных типах? В стандартном случае - их надо заполнять и там и там?
Я правильно понял? Если так - вот тут как мне кацца и ошибка в проектировании.
Вот я и не хотел бы дублировать, а иметь эти поля только в "составных частях товаров", но выводить их (использовать) и на страницах с "товарами".
Загвоздка в том, что надо их выводить не только на самих страницах товаров (single page), но и на страницах с большим списком "товаров" (archive page и подобное). Здесь я упираюсь в слишком большую нагрузку на сервер (куча query из БД).
А что представляют собой эти 3-4 метаполя (ака Custom Post Fields)? Какой содержимое?
Данные с цифрами. Некие Integers, которые надо будет не раз менять. Хотелось бы не менять их ручками по всему сайту, а только в Custom Post Types "составная часть товара", где они уникальны для каждого CPT.
Вот такая засада.
В хедер цепляю код логинзы а она иногда тупит, поэтому страница часто "подвисает"
JavaScript, верно?
Тогда оберните сам код JS в:
$(document).ready(function() {// код
});
Или, если подключается файл JS с кодом, подключайте его в конце страницы.
Это разумнее, нежели переделка всей верстки.
и спрятать уникальный контент от злоумышленников
Вор боится другого вора.
Как мило...
SeVlad, полностью поддерживаю.
ТС-у бы азы хотя бы освоить. Судя по коду, найденному на "сайте" в старт-посте, знаний у человека почти ноль...
Подскажите как называется такой эффект в дизайне чтобы сделать такой переход как на фото ниже?
Градиент "глянец".
Поиграйтесь.
Может ли быть причина в этой кнопке? Плагин javascript:history.back();
Нет.
10 симв.
на Хецнер Яндекс часто ругается) при этом не на все сайты. отвалится на полчаса - заработает, потом неделю все нормально
Никогда подобного не наблюдал...
Че мелочитесь-то...
Да запихайте всё в h1 - потом нам расскажите... ))
Что за глупое сравнение H1 и DIV?
Для асобо одарённых поясню ::: после тега <p> - на нормальных сайтах идет "контент".
А "контент" на странице - априори самое главное!
Бред полный.
<p> лишь указывает, что это -- параграф, а не "самый важный контент".
Открою вам секрет: если хотите указать на своём сайте где именно главный контент находится, откройте для себя role="main" (а для остальных частей сайта другие role) и <article>.
Делаем таблицу старыйадрес-новыйадрес.. индекс по старому адресу (если адреса сильно длинные - можно хэш какой-нибудь использовать)
в корневом index.php (ЧПУ ведь наверняка используется) подключаем файл, который делает 1 доп запрос к базе на предмет наличия запрошенного URL в таблице редиректов. Если есть - редиректит.. Если нет - возвращает выполнение на основной сайт.
Поиск по индексу в 30к операция не такая уж ресурсоёмкая.
Да, и так можно, наверное.
Но лучше делать структуру нового сайта похожей, чтобы легко было использовать regexp в редиректах.
И это должно быть легко, если движок самописный.
Но, судя по озвученному ТС, там вряд ли самопис, а программер - новичок.