Вот напиши это кто другой — я бы не поверил.. Не поверил бы, что такое возможно насамописить :)
Это шедевр самописов ящетаю. В ананлы!
И да, это таки работа не сеошника ;)
Но у ТС другая ситуация — Друпал. Настолько гибкий и мощный двиг.. одновременно и хрупкий, если лезть напрямую в базу или файлы не зная хорошо движка.
Это моя боль.. сешникии, недалёкие вебмастера и наоборот, крутые кодеры (они порой опаснее для сайта, чем даже сеошники :( ) такого наворорят в движках, что потом нужно всё делать с нуля, а на это у клиентов нет денег. И мастырят костыли, мастырят, пока совсем всё не развалиться. Зато когда-то сэкономили на специалисте.
айболит на крон и ещё 100500 вариантов.
А можно ещё лучше - /ru/forum/697566 или аналоги.
И так и не так. Это механизм мутный-сложный, но всё же реально с большой долей вероятности не пропустить случайные фото-видео. Хотя бы уже тем, что камеры и ракурсы не те, и никогда не будет 100% повторений (т.е. если были перехвачены прошлые данный, то второй раз они не прокатят — защиту от их повторения сделать достаточно просто).
Обратная сторона это медали — будет баниться и легитимная авторизация.
А я и не говорил, что конфетка :) Как раз наоборот, если ты не видел что я писал на прошлых страницах. Я даже с тобой согласен почти во всём.
Но… ты мог подумать лет 15-20 назад, что какой-то «обмен фоточками» может вырасти в огромный проект, родить корпорацию, собирать и манипулировать огромными массивами данных? Не просто данных, а данных человеков.
А что любая домохозяйка, не подозреваюзая даже об html может за полдня слепить нечто, что гордо будет звать «сайт»?
Это я к тому, что не всё то, что кажется сегодня фуфлом таковым окажется со временим. Тем более такие вещи, как сбор данных биометрии. Это будущая часть бигдаты..
Во первых, см выше. Я говорил про защиту от повторяемости. Если сам подумаешь без нервов, то думаю, поймёшь о чем я.
Во-вторых - узко смотришь. Применять для форумов/комментов возможно и мелко, а вот как первая линия напр… не хотел подсказывать, но да ладно, дурачки всё рано заюзают.. для неадватных хостеров - вполне.
Это совершено разные специальности и навыки.
Это и есть вебмастер. (Про линкс, правда, знать достаточно основы - особенности ФС, кодировки, права и тп).
А описанные тобой выше (в тч. установщики CMS из панелек хостеров) - домохозяйки. Им-то уж точно "администрирование серверов" покруче высшей математики будет :)
Реальность такова, что вот ты, напр, технически грамотный, можешь кодить и понимаешь смежыне специальности. А 90% нынешних сеошнегов даже правильные разделы на сёрче не в состоянии нагуглить :). Вот это реальность. Вот это показатель квалификации ящитаю.
И да -
Работа с базой - это НЕ администрирование серверов, а элементарные навыки вебмастера. Речь же не о развёртывании MySql на сервере (хотя это тоже "на стыке" админсва и вебмастерсва ;) ).
В данном же случае ещё немаловажно, что это не абстрактная база, а процесс миграции сайта. Напрямую связано с движком.
А он изначально неправильно делает (и наверняка наделал намного раньше), что тоже касается вебстроительсва, а не администрирования.
Динамика ибо может быть (да, поморгать-попукать). Должна быть. Без неё это вообще ОППА.
А кстати, это тоже вполне реальное применение. Без смайликов. И гораздо шире, чем просто "капча".
Жаль, что ТС игнорирует вопросы и только надувает щёки :( Но наверное действительно сказать нечего, нет элементарного понимания, а всё это просто езда по ушам для домохозяек и глупых горячих инвесторов.
Это только первая проблема из-за неправильного переноса ВП. А сколько их ещё появится…
Только причём тут администрирование серверов?
А, да. Кривыми переносами ты убил автоинкремент и похерил индексы.
Это плохо, очень плохо.
Как ты это себе представляешь?
Прежде всего потому, что в базе много зависимостей, временных данных и хранение в сериализованных массивах. См https://codex.wordpress.org/Database%20Description
Кроме того - структура базы и данных может поменяться при обновлении. Такое уже было неск раз в истории ВП. Соответственно, всё может поломаться.
При чтении (как в данном случае) ты конечно не повредишь базу, но легко можно получить неверные результаты. А вот когда так изменяют данные, и тем боле добавляют — это очень опасно.
Поэтому нужно просто привыкать использовать функции/апи.
(Ок, пароль можно изменить руками. А вот логин или домен уже нет. Логин вообще менять нельзя).
«Руками» — значит прямыми SQL запросами в БД или непосредственно в РМА или аналогах.
Может времени? get_posts не быстрая функция.
Кстати, а какова цель получения всех ИД? Зачем и где потом должно использоваться?
Ну хорошо, что тут хоть специальный класс использовал . Это более безопасно, но без особой нужды и его не стоит трогать. Во всяком случае до хорошего понимания ВП.
А это, кстати, хороший пример/объяснение почему нельзя использовать прямые SQL-запросы - ты нарвался на префикс таблиц. А он не должен участвовать в запросах/коде, тк его можно изменить и при установке ВП и даже после (хотя это не стоит делать на рабочем сайте).
Ну справедливости ради, в данном случае (использование wpdb) более-менее нормально. Хуже было бы если бы голым SQL полез.
seovisor, если хочешь понять ВП и что делает код см. как надо делать: увидел функцию (как напр get_posts, что показал AGRESSOR ) — идешь в кодекс (и новый, пока не полный) или на https://wp-kama.ru/functions и ищешь там функцию, изучаешь. Функции имеют логически и интуитивно понятные названия, так что поиск нужной тоже не составляет труда. Ну а так, если что надо сделать — лучше переспросить на форуме, подскажем как лучше/правильнее/безопаснее решить задачу.
