sitecreator

Пользователи
  • Число публикаций

    2 823
  • Регистрация

  • Последнее посещение

Репутация

395 Очень хороший

5 подписчиков

О sitecreator

  • Звание
    Искушение сдаться будет особенно сильным перед самой победой

Информация

  • Пол
    Мужчина
  • Город:
    USSR Moscow

Контакты

  • Skype
    sitecreator.ru (бываю не часто, пишите в личку)

Недавние посетители профиля

14 659 просмотров профиля
  1. Дык спать хорошо бы, а не вставать ни свет ни заря. Девушкам это самое полезное! Я тут в лесопарке в 05-30 гулял, думал, что никого не будет, ибо рано вроде бы. А народ уже на турнике крутится, с собаками гуляют, девушки фитнесом занимаются. и когда они высыпаются?
  2. https://opencartforum.com/forum/84-группы/ Отчего все группы закрыты кроме единственной? Что секретного обсуждается в "SEO CMS" или в "NetBeans IDE", или в "Snippets and useful information!"? Особенно насчет последней непонятно. Как человеку вообще определить нужно оно ему или нет? Да и помнится, что я был в одной из групп ранее, а теперь пароль какой-то хочет... Не то чтобы я стремился попасть в "NetBeans IDE", просто любопытно стало. Открытая IDE, а тут так все туманно. Я ей не пользуюсь, хоть и пробовал (не понравилось для php), но подозреваю, что там и сообщений, скорее всего, нет никаких. Отчего закрыто даже для чтения? А как тогда стимулируется интерес к этой группе?
  3. тут один прикол вспомнил. Ни заказчик, ни дизайнер понятия не имели, что такое вьюпорт и рисовали макет исходя из физического разрешения экрана Ретина! Поэтому там где вьюпорт (iPhone 5) равнялся 320, но у заказчика получалось 640! И он искренне никак не мог понять почему весь его дизайн не сможет уместиться. Т. е. заказчик изначально заложил глупость в проект, а дизайнер, не моргнув глазом, поддержал эту глупость. В итогу был дизайн-макетет, который вообще никак не был рассчитан на смартфоны, но зато поддерживал мониторы-монстры 2048 точек. И при этом никакой адаптивное сетки не предполагалось вообще. на сайте-примере для подражания это были пончики (хлебобулочные изделия) аля ассорти из 7 шт. Функционал минимален, тут, видимо, главное чтобы было "прикольненько" нарисовано. Вот для такого дела как раз сгодится любой креативный дизайнер, на движок можно не оглядываться вообще. Если есть опыт рисования книжных обложек - вот этого будет достаточно. Все магазины из-за переизбытка информации сейчас делаются в минималистском дизайне. Для продажи одежды важно чтобы посторонние детали не отвлекали собственно от самого важного - товара. Оформление не должно затмевать товар. Собственно как рамка к к картине не должны отвлекать внимание от картины, только дополнять ее. А с одним товаром, будь то напиток или пончики нужно просто на странице передать настроение и создать иллюзию, что именно товар поднимает настроение. Сам товар - это вторично. Известный рекламные прием. Покажите молодых людей, катящих в кабриолете и пьющих Колу - и все захотят купить и пить Колу! Примерно так.
  4. полностью поддерживаю. не понимаю эту бессмысленную работы по рисованию прямоугольников в фотошопе и тщательный подбор (в том же фотошопе!) теней к этим прямоугольникам. На сегодня все делается средствами CSS. Более того, макет в фотошопе всегда содержит массу ошибок и непродуманных моментов. Начиная с того, что дизайнер-полиграфист не имеет никакого понятия об адаптивной сетке. И рисует так, если вообще рисует, макеты для разных разрешений, что они в принципе нереализуемы на реальных устройствах, ибо происходит конфликт для разных разрешений - невозможно подобрать адаптивную сетку чтобы не происходило наложений, появления горизонтальных прокруток не к месту и прочих коллапсов. Корень зла - про адаптивную сетку не слыхали. верно. еще нередко в работу вклинивается "родственник" верстальщика по профессии "натягувальщик" Ибо без главного натягувальщика 6-го разряда процесс рискует быть вообще незавершенным, т. е. ни разу ненатянутым. Верстальщик сверстает голый абстрактный HTML, а там хоть трава не расти. -------------- а если вернуться к нашему заказчику, то, как я понял из переписки, нужен вовсе и не магазин, а лендинг-пейдж для продажи одного товара. Продажа путем ввода во всплывающем окошке имени, телефона и адреса.
  5. сразу видно человека, не по наслышке знающего, что такое магазин одежды. Я в свое время на один магазин потратил несколько месяцев пока заказчика устроило все. Одна из жесточайших болей была выгрузка в Маркет. И учет, учет и еще раз учет. Импорт из прайсов поставщиков - тоже не менее занимательная задача. Со связанными опциями работал. На тот момент, так случилось, что я был типа бетатестера (по словам разработчика), т. е. багов было достаточно. Сейчас, думаю, что тех уже нет. Но больше всего меня напрягло очень и очень утомительное заполнение вручную. Пока я заполнил 10 футболок разного цвета и с разными картинками я чувствовал себя изможденным - такое обилие всевозможных вкладок и кликаний мышек! Те же самые обычные 10 товаров с разными картинками, артикулами, цветами и размерами я бы заполнил значительно быстрее. Возможно, что это с непривычки мне сложно было заполнять связанные опции. Возможно, что в новых версиях заполнение упростилось - этого я не знаю. Просто будьте готовы к трудностям. И с точки зрения SEO отдельные ссылки на товары разного цвета, возможно, что это лучше чем одна ссылка на кучу товара разного цвета. Есть, так сказать, маневр для SEO - текстов. Этот вопрос специально не исследовал. Верно. К этому склоняются очень многие, кто работал в продаже одежды. Один из магазинов я переделывал с нуля, поскольку заказчик попробовав в течение 2-х лет разные варианты, все же пришел к единственно правильному (по его мнению) решению: один цвет - один товар. В данном случае учет нужно будет вести именно по опциям (размерам одежды). Каждой опции размера можно сопоставить свой артикул. Tom верно указал модуль. Но под актуальные версии, возможно, его нужно дорабатывать. Я имею ввиду 2.3. Код в принципе открытый, а потому особой проблемы в этом не вижу. При желании можно было бы и дальше развить проект. Хотя вижу сообщение, что тут уже адаптировали под 2.3. Ага, да и сам Tom это подтверждает.
  6. Дело в том, что по умолчанию, опенкарт не предполагает, что опции - это отдельные независимые товары от "основного" товара. Именно эта проблема, в том числе с учетом, вылезает на таких товарах как одежда. И связанные опция решая одну проблему могут создать вам кучу других проблем. Например, возможные проблемы: вы не сможете выгружать данные на Яндекс-маркет. Или вы не сможете работать с различными системами учета вроде 1С. В третьих, связанные опции довольно сложно заполнять. т. е. трудоемкость процесса повышается. Не каждый модуль импорта умеет работать со связанными опциями. Если вам нужна выгрузка в Маркет и другое, то поинтересуйтесь насколько связанные опции к этому приспособлены. Глянул на вашу локацию - для вас неактуально. Для работы 1С в случае связанных опций вроде бы есть решение. По крайней мере, по заявлению автора. Хотя, и это для вас неактуально. Вам упростило задачу государство. Сам работал с одеждой, а потому знаю насколько в этой теме все непросто. использование связанный опций - один из вариантов со своими недостатками. Еще есть возможность, и на мой взгляд это наиболее верное решение, использование для каждого товара определенного цвета/модели индивидуальной карточки товара. Т. е. не использовать цвет как опции. Как опции только размеры. Товары одного фасона/модели объединяете в группу. Для каждого товара есть своя индивидуальная ссылка. Но для покупателя на сайте товар будет показан как один если несколько цветов. Просто при клике по цвету вы переходите на такой же товар. По такому принципу работают очень серьезные магазины одежды. пример: http://www.lamoda.ru/p/ba007ewhrn19/clothes-baon-futbolka/ И не будет проблем с учетом, артикулами. Как один из вариантов. Готовое решение не могу подсказать для 2-й ветки, т. к. последний раз работал с одеждой на ветке 1.5
  7. слишком много переверстывать нужно. 2 ряда вы имеете ввиду при пейзажном положении? так у вас и так 2: а если при портретном положении так маловато места для двух товаров. целиком два товара уже на один экран не поместятся. Ваш длинный текст станет неудобно читать в блоке малой ширины. По одному слову на строку получится? А длинное слово вообще может не получиться. В итоге вы скажите, что "не так себе это представляли" и будете недовольны результатом. А это может запросто произойти. Телефонная трубка, которая дергается и мигает постоянно - это жутко раздражающий фактор. Не всем нравится. На мой взгляд это не комильфо.
  8. дизайн, верстка, программирование - к вашим услугам. только у веб-дизайнера. Я, правда, ни разу еще не встречал дизайн сайта от веб-дизайнера, все только от дизайнера-полиграфиста. С соответствующей спецификой. Потом заказчик удивляется почему высота шрифта другая чем в макете (там она в pt, а не в пикселях), почему цвет и сглаживание другое. Нелегко объяснять почему специфическое сглаживание шрифтов в фотошопе (а там свой рендеринг шрифта), рассчитанное на типографию, невозможно в браузере. И куча всяких других моментов. Плохо когда дизайнер не представляет, что такое Opencart, а потому рисует трудновыполнимые (и часто ненужные) функции и при этом ухитряется не нарисовать полезный функционал, который есть В Опенкарте. особенно умиляет, когда дизайнер изобретает велосипед, рисуя некое подобие быстрой формы оплаты. SergeyWH вы не указали, что именно нужно сделать. Разработать магазин с нуля или одну страницу или баннер?
  9. обязательно проверяйте конфиг: nginx -t а далее перезагрузка nginx systemctl reload nginx.service Теперь еще тонкость. ОЧЕНЬ ВАЖНО если у вас настроено автоматическое продление (генерация) сертификата. Важно чтобы не только был правильный конфиг с точки зрения самой nginx, но и с точки зрения ISPmanager-а, который проверяет сам конфиг на ошибки по своим алгоритмам. Так уж случилось, что ISPmanager несовершенен и находит ошибки в совершенно верном конфиге nginx. Такое иногда случается. В таком случае когда настанет час Х (авто-генерация сертификата), то должен автоматически переписаться конфиг с новыми данными сертификата. Но если исправный конфиг (по версии самого nginx) не проходит проверку на синтаксис в ISPmanager, то вас ждет неприятность. Конфиг с новыми данными сертификата не вступит в силу, а сайт окажется недоступным из-за просроченного сертификата. Некоторые продвинутые хостинг-провайдеры знают об этой проблеме. Из пользователей мало кто знает. Поэтому обязательно делайте проверку средствами ISPmanager вашего конфига. Если получается так, что ваш рабочий конфиг не проходит проверку через ISPmanager, но он вам нужен, то разбейте конфиг на две части: основную (которую будет проверять ISPmanager) и дополнительную с "ошибками " (по версии ISPmanager, но без ошибок по версии nginx). В основную автоматически ISPmanager будет вносить изменения когда нужно сменить сертификат. Он проверять будет только ее. А дополнительную часть нужно уже инклюдить к основной. Об этой тонкости мало кто знает. Даже гуру порой...
  10. Может возникнуть ситуация когда нужно получить доступ к статистике Яндекса по сайту без https, особенно если вы переходили на https и вам нужно сравнение информации (от Яндекса) как было "ДО" и "ПОСЛЕ". Тогда вышеприведенный конфиг не позволит Яндексу прочитать свой ключ по адресу http (без S), а Яндекс может попросить такой ключ, т. е. подтвердить ваши права. И это не смотря на то, что права на сайт с https у вас уже есть. Тогда нужно сделать модификацию в первом блоке server И Яндекс сможет получить доступ к своему ключу. Не забываем, что для Яндекса сайт с http и с https - это два разных сайта. server { server_name site.com www.site.com; listen *.*.*.*:80; if ($request_uri != "/yandex_ваш_ключ.html") {return 301 https://site.com$request_uri;} # ниже путь к корневой папке вашего сата (там и ключ яндекса) set $root_path ......; root $root_path; } server { server_name www.site.com; listen *.*.*.*:443; return 301 https://site.com$request_uri; ssl on; ssl_certificate "..............crtca"; ssl_certificate_key ".............key"; ssl_ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH; ssl_prefer_server_ciphers on; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; add_header Strict-Transport-Security "max-age=31536000;"; } server { server_name site.com; listen *.*.*.*:443; ssl on; ssl_certificate "..............crtca"; ssl_certificate_key ".............key"; ssl_ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH; ssl_prefer_server_ciphers on; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; add_header Strict-Transport-Security "max-age=31536000;"; ........ ........ }
  11. я указал немного выше на недочеты. и прямо перед этим постом и есть рабочий конфиг в плане редиректов. вся остальная информация заключена в третьем блоке server. Для нормальных редиректов нужно именно три блока server. Ниже распишу еще разные хитрости.
  12. Как правило, если сайт использует протокол https, то ссылки вида http://site.com http://www.site.com https://www.site.com должны вести на https://site.com (если именно это является главным зеркалом вашего сайта) т. е. делаем редирект 301 c www (оба протокола) на "без www" (https) Тогда конфиг сайта может быть таким (вместо звездочек IP сайта): server { server_name site.com www.site.com; listen *.*.*.*:80; return 301 https://site.com$request_uri; } server { server_name www.site.com; listen *.*.*.*:443; return 301 https://site.com$request_uri; ssl on; ssl_certificate "..............crtca"; ssl_certificate_key ".............key"; ssl_ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH; ssl_prefer_server_ciphers on; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; add_header Strict-Transport-Security "max-age=31536000;"; } server { server_name site.com; listen *.*.*.*:443; ssl on; ssl_certificate "..............crtca"; ssl_certificate_key ".............key"; ssl_ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH; ssl_prefer_server_ciphers on; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; add_header Strict-Transport-Security "max-age=31536000;"; ........ ........ }
  13. на мой взгляд, очень много кода. И знатоками nginx не приветствуется использование if без необходимости. Об этом и на официальном сайте написано. Все делается несколько проще. И без if. Также еще нужно учесть один момент, что в ISPmanager есть ссылка на phpmyadmin. И она должна работать без конфликтов. Это не всегда учитывается. Дело в том, что ссылка на phpmyadmin формируется таким образом (автоматически в ISPmanager ), что она по идее должна работать при обращении не только по IP сервера (IP/phpmyadmin ), но и по любому адресу вроде сайт.com/phpmyadmin. Точнее, скорее всего, предполагалось, что будет использоваться только ссылка IP/phpmyadmin (по обычному или SSL протоколу), но из-за особенности конфига phpmyadmin-а на phpmyadmin будут ссылаться и ссылки вида сайт.com/phpmyadmin. Так вот когда используется сертификат для сайта и псевдо-сертификат для доступа по IP (к ISPmanager и phpmyadmin ), то могут возникнуть забавные коллизии, вплоть до того, что вы не сможете попасть в phpmyadmin. Это нужно учитывать. Также у вас есть некоторые неточности. секция server не будет работать без сертификата если вы собрались делать редирект с https. Браузер просто напросто тормознет на этом моменте (нет сертификата!) и не будет никакого редиректа. Это также нужно учитывать когда делаете редирект с www на "без www" (и наоборот) используя протокол SSL. Я уже в одной из тем публиковал рабочие конфиги. На сегодня я их немного модифицировал, учитывая разные практические соображения, которые только практика и смогла подсказать. ------------------ В принципе можно считать нормальным, что когда из ISPmanager вы переходите по ссылке: http://***.***.***.***/phpmyadmin/ то попадаете на httpS://site.com/phpmyadmin/ Если у вас сайт единственный (и он с SSL) или он самый верхний получается в конфиге NGINX, то так и будет. Если сайтов нет, то тогда доступ будет только по IP. Но можно настроить так, что будет работать всегда http://***.***.***.***/phpmyadmin/ Кстати, в последних версиях ISPmanager отказались от ссылки httpS://***.***.***.***/phpmyadmin/ т. к. возникали проблемы с доступом. Любые возражения и конструктивная критика принимаются. Аргументация на уровне "сам дурак" или "бред", думаю, что больше подойдет для проповедей в секте свидетелей противников nginx.
  14. вирус, вирус.... у меня во чего случилось сейчас при переходе по ссылке на этом форуме
  15. и я встречал. справедливости ради нужно сказать, что админер или дампер работает быстрее чем штатный phpmyadmin (это когда к нему доступ есть, нередко заказчик и этого не дает). Более того, в ряде случаев только этим сторонним софтом как раз таки и можно загрузить большой дамп, не опасаясь наступления лимита времени. Да и вообще, как мне кажется, для подстраховки исполнитель может сделать резервную копию сайта (и БД) перед работой. А вдруг что-то не так пойдет - а тут вот есть копия. Разве это неразумно? Но вопрос был несколько в другом. оставленный хвост после работы в виде админера, дампера - это хорошо или нет? или вообще ни на что не влияет? Т. е. считаете ли вы это нормальной практикой - НЕ УДАЛЯТЬ эти вроде бы безобидные хвосты?