Поставьте Web-сервер, например Apache, хотя в php есть встроенный для таких простых вещей. Или редактируйте напрямую на сервере, т.е. возьмите хостинг и вперед.
AJAX'а это тоже касается, только не отображайте данные в контролах для не редактируемых в тек. момент записей или отображайте статус «требует сохранения» для тех записей, кот. пользователь отредактировал, но не сохранил.
Для изменения и т.п. можно использовать чекбоксы, индивидуальные формы, кнопки с собственными обработчиками и т.п.
Значение $ident должно как-то передаваться в обработчик.
Но если нет знаний и опыта, то тут конечно остается надеяться только на примеры, хотя и это не совсем правильно, потому что пример != готовое решение. Лучше заплатите кому-нибудь, если нужно срочно и нет желания учиться в экстремально ускоренном режиме.
О каком конкретно действии идет речь? Если о просмотре, редактировании (именно редактировании, а не сохранении отредактированного), то достаточно простых ссылок и метода GET.
Для изменения и т.п. можно использовать чекбоксы, индивидуальные формы, кнопки с собственными обработчиками и т.п. (Добавление)
Значение $ident должно как-то передаваться в обработчик.
Идентификатор конкретной записи указывайте в ссылке, в имени кнопки и т.п. Потом обрабатывайте запрос.
Вот, например, почитайте мою статью Как сделать вывод списка статей? и обязательно комменты к ней, т.к. в самой стать предполагается использование движка, который сам выбирает отдельные записи. (Добавление)
P.S. Вот это переливание из пустого в порожнее: $numid = $myrow['num_id']; и т.п.
Используйте какое-нибудь современное расширение для работы с БД, например mysqli.
В шаблоне лучше использовать альт. синтаксис (см. шаблоны в статье).
Соединение с базой лучше закрывать до выполнения шаблонов или вообще этого не делать, полагаясь на «сборку мусора».
А что это вообще за концовка? Выборка всех комментов для их вывода что ли? Я вам в пред. посте писал, что в запросе нужно как минимум указать условие с id статьи.
Цитата:
думал ещё передавать значение через
Это все детали. Главное, что все же в адресе передаете, а не в POST-параметре. Можно частично использовать общий код для обоих типов запросов (действий). При проверке корректности id, например. Адреса в запросах будут одинаковые. Лучше конечно в пути передавать. И не числовой id, а слаг, чтобы получились красивые ЧПУ, например http://g09[dot]ru/articles/my-first-article .
И разберитесь прежде с основной логикой, после уже будете про всякие strip_tags думать. (Добавление)
P.S. При ошибке вставки можете перенаправлять, например, на '/error'.$_SERVER['REQUEST_URI'], либо по возможности сохранять данные, но выставлять «флаг скрытности», если что-то не так. Короче полет фантазии не ограничен. И программирование – это удовольствие, а у вас пока получается напряг
Вы же использовали GET-параметр для идентификации страницы (что вполне допустимо). Так проще поставить на автомат проверку существования данной страницы. Комменты-орфаны точно никому не нужны. И существование каждого POST-параметра отдельно проверяйте. Эта проверка может быть заменой вашей "if(count($_POST) > 0)".
Цитата:
передает id страницы (статьи), не могу понять как составить правильно запрос чтобы мне выводило комментарии только те которые относятся к данной статье. Мне же щас выводит все статьи.
Мне кажется, проще разделить по виртуальным хостам. Такое шаманство зачастую отнимает ресурсы у фронта. Еще гляньте в сторону автоматических вирт. хостов (mod_vhost_alias VirtualDocumentRoot).
Сходу трудно дать вам ответ, который бы вас устроил. Все зависит от структуры вашего сайта и от его админ. панели. В простейшем случае файл картинки может по щелчку загружаться в опред. каталог под опред. или оригинальным именем и тут же вставляться в содержимое соотв. тег с уже готовой ссылкой.
Часто можно встретить и разделение загрузки и собственно вставки, но конечно не такое, как вы это описали. Сначала картинки для редактируемого материала скопом загружаются на сайт через Web-интерфейс (например, в каталог, ассоциируемый с редактируемым материалом), а затем уже расставляются по местам.
Канонический – это просто осн. адрес, если у страницы их несколько. Применительно к выдаче контента/редиректу это тот адрес, под кот. выдается контент, а не делается редирект. Под разными адресами идентичные страницы лучше не выдавать вообще. Хотя можно использовать то, о чем вы говорите, но rel=canonical все же предназначено немного для другого, а для идентичных страниц его используют только те, кто не в состоянии избавиться от дублей техническими средствами.
Легкое готовое решение – это наш движок. Если бы я хотел вам его продать, я бы сразу об этом сказал. У нас тут вроде доверительная беседа без какой-то коммерции (не, вы конечно можете по итогам успешного разрешения вашей проблемы в порыве чувств бросить мне на пивко, но я спокойно переживу, если вы этого не сделаете ). Только пообещайте не распространять, чтобы не нагружать вас лицензионной морокой. Там несколько файлов всего. Сейчас скину ссылку на описание.
Еще раз: только через .htaccess для 800 страниц не получится. Не забывайте, что вам могут подложить к каждому идентификатору дофига левых слагов, а не только тот, который вы сами придумали. Если где-нибудь появятся подобные левые бэки, ПС их начнут хавать и вам выписывать дубли! Такое вполне вероятно, даже если не брать в расчет проделки конкурентов. Кстати, 800 страниц – это немного. Тут самое сложное слаги наклепать. Или вы их тоже как-то автоматом генерируете? Даже если оставлять в адресе ваши оригинальные идентификаторы, нужно модифицировать движок на предмет проверки слага после выборки записи по оригинальному идентификатору, т.е. если в адресе поступает корректный слаг вы выдаете штатный контент, иначе – ошибку 404 или делаете редирект на каконический адрес (с корректным слагом).
Цитата:
По поводу хака, вы имеете ввиду редирект на php аля header location?
Ну да. Слаг для редиректа по каноническому адресу нужно же откуда-то брать. Лучше всего брать из той же таблицы БД с данными соотв. страниц (надеюсь, вы используете БД для хранения осн. контента. Или нет?). Еще обратите внимание на такой момент: редирект можно делать только для старых адресов без слагов, а для новых адресов вроде /артикул/левый-слаг можно ограничиться 404-ой ошибкой.
Цитата:
Да, вдухкомпонентные слаги не камельфо, в идеале оставить /my-page.html
Это сложнее сделать. Нужно использовать идентификацию слагами, хотя у вас и так использовались нечисловые идентификаторы (артикулы), т.е. нужно просто искать по полю со слагами, а не с артикулами. Поле, естественно, должно быть первичным ключом или юником.
Гляну еще ваш сайт. Может, получится подобрать какое-нибудь легкое готовое решение. (Добавление)
Есть подходящий двиг именно для вывода страниц по каноническим адресам. Можно без проблем сделать разные форматы адресов для страниц продуктов:
/слаг-в-нижнем-регистре
/product/слаг-в-нижнем-регистре
и даже
/артикул-желательно-в-нижнем-рег истре/слаг-в-нижнем-регистре
/слаг-в-нижнем-регистре/артикул-желательно-в-нижнем-регистре
(в нижнем регистре, потому что двиг SEO-ориентированный и будет пытаться автоматом понижать регистр, делая лишний редирект, если в адресе есть большие буквы; для нек. поисковиков разный регистр букв – это тоже дубли)
Фишка в том, что вам не нужно модифицировать product.php, навешивая на него доп. функционал (делая вилку «контент/редирект»). Вы просто делаете в product.php редирект со старых адресов (если есть желание, при ошибках можно отдавать управление в движок). Движок штатно отдает приоритет при обработке адресов, содержащих имена существующих файлов. Он нативно обрабатывает ЧПУ, т.е. промежуточные внутренние адреса вроде /product.php?id=100500&sid=my-page ему в принципе не нужны, но вы в вашем product.php можете делать редирект и с этих адресов – просто не обращайте внимания на наличие доп. GET-параметров и делайте редирект только по значению GET-параметра с идентификатором (артикулом).
При желании потом под него загоните и др. страницы сайта. Как я понял, они основаны на отдельный файлах, либо файлах с GET-параметрами (в вебдеве это называется «множественные точки входа»).
Изначально страница доступна: product.php?id=PP361
После появился дубль: product.php?id=PP361&sid=my-page
который преобразуется в product.php/PP361/my-page.html
Один и тот же товар доступен по двум ссылкам: product.php?id=PP361
и product.php/PP361/my-page.html
А, это тот же сайт, который вы уже показывали. Исходные идентификаторы весьма странные, с буквами. В этих буквах что-то закодировано? Вам зачем вообще уровень вложенности в адресах повышать? Какие-то конфликты что ли мешают или пытаетесь скорость доступа увеличить за счет деления на группы? Гораздо проще, как ранее писал, оставить одни слаги (символьные идентификаторы). Вы, видимо, дописывали слаги к осн. идентификаторам, чтобы преобразование адресов делать в .htaccess по осн. идентификаторам, используя «мусорные ключи» чисто для SEO. Общими правилами в .htaccess тут не обойдешься – «мусорные ключи» нужно контролировать: либо прямо в .htaccess прописывать индивидуальные правила (что нереально для большого кол-ва элементов), либо сопоставлять поступивший слаг с хранимым в запрошенной записи и при несовпадении делать редирект на канонический адрес.
Я вам рекомендую перехватывать хаком (отдельным скриптом, запускаемым при запросах по адресам опред. формата) старые адреса и делать редирект на новые, в которых бы был только слаг без старого идентификатора. Чем городить такие двухкомпонентные пути, как вы показали, лучше просто добавьте компонент, указывающий на тип страницы, т.е. речь об одном из след. двух вариантов адресов:
/my-page.html
/product/my-page.html
Расширение – это сейчас рудимент, но в принципе можно оставить. Слаг product всегда один и тот же.
Цитата:
у меня сапомисный движок))) с бесплатными движками я уже намучался и они не удовлетворяют моим потребностям в функционале
Это похвально. Движок сами писали или кто-то помогал? (Добавление)
Рекомендацию не дописал... Для работы новой адресации, естественно, нужно делать идентификацию страниц на основе слагов. (Добавление)
Если идентификацию на основе слагов трудно реализовать, контроль слагов и редирект при несовпадении по-любому нужно делать.
Когда я писал выше, я подразумевал, что адрес с GET-параметрами тоже с натяжкой можно назвать ЧПУ. Теперь, как я понимаю, под ЧПУ вы подразумеваете адрес с путем вместо строки параметров. Т.е. делать редирект нужно примерно так: /?id=100500 -> /my-page (без промежуточного редиректа на /?id=100500&sid=my-page). (Добавление)
Редиректы с неЧПУ в ЧПУ легко делаются при помощи хаков, плагинов и т.п. В популярных движках/CMS иногда поддерживаются прямо из коробки, например в WP. У вас какой движок?
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 129
). Только пообещайте не распространять, чтобы не нагружать вас лицензионной морокой. Там несколько файлов всего. Сейчас скину ссылку на описание.
