LEOnidUKG: Кто взламывает тот продаёт за приличные финансы это или юзает сам.
бла-бла-бла..
Ты говорили про решето. Подтвердишь свои слова делом (хотя бы ссылкой на успешный взлом. С описанием ессно - через что и как это произошло) или сольёшься как и все остальные балаблолки?
LEOnidUKG: Мы не базаре и не за пивком.
Я всё больше убеждаюсь, что акк LEOnidUKG-а угнали.
llppzz: Еще раз для упертых - ICANN не находится под управлением США.
Я тоже ещё год назад не мог и в страшном сне представить, что произойдёт..
И даже несколько дней назад не многие из этого топика - в участии в нём.
Я к тому, что это вопросу веры, не более.
Но началось всё не с этого, а с предложения некоторых съезжать с комов в рушки. На что я как бэ предложил подумать о целесообразности и разницы\последствий.
И что? Я разве говорил, что в ВП не было и не будет никаких уязвимостей? Разве я когда-то отрицал, что они есть? Разве я говорил, что ВП - идеальная безопасная система?
Вопрос был такой:
SeVlad: Покажи когда последний раз был взломан ВП.
Можем сделать по- другому: я поставлю голый ВП. Кто взломает (в разумные сроки, разуется) - обещает подробно описать как был осуществлён взлом. Кто-то возьмётся? А то тыкать в опубликованные разработчиками (и пофиксенные) уязвимости дело не трудное. Вот воспользоваться ими - дело другое. :)
ICANN (читается айкэ́н[1]) — международная некоммерческая организация, созданная 18 сентября 1998 года при участии правительства США ... Сегодня в ICANN проводится комплекс мер по выводу корпорации из-под контроля правительства США. [3] ... Офисы ICANN расположены в Лос-Анджелесе, Брюсселе, Сиднее и Вашингтоне,
Связи типа "многие-ко-многим" требуют промежуточную таблицу.
В самой базе может не быть видно прямых связей (зависимостей), а только в самом же движке жестко прописано какое поле в какой таблице нужно использовать.
Проще говоря по БД может не быть видно что значение в поле ID_metadata в таблице tbl_meta тоже самое, что и в поле ID_post в таблице tbl_content.
И это не самый сложный случай. Бывает, что к ИДшику поста "подязываются" данные из нескольких таблиц, при этом не по ИД поста, а через одно или несколько промежуточных данных.
nomarketing: Ну все таки один вопрос остается пока не решен это удаление дубликатов + ассинхронное удаление по айди из другой таблицы
Так ты же сказал:
nomarketing: Как бы я удалял сообщение не отслеживая связи ? или как бы движок удалял пост не отслеживая связи ? мол пост удалили а картинки которые идут в другой таблице под тем же айди удаленного поста оставим ? ну уж нет ну вообщем не в этом проблема щас.
Мне кацца, тебе надо как-то с этим определится :) В см со связями и отслеживанием оных.
nomarketing: Вообщем есть, база, в ней есть 6к сообщение, из 6к сообщение наверно 1.5к дубли.
В базе не "сообщения", а "данные". "Сообщения" - в движке. Соответственно только движок может знать (а может и не знать) все связи этого сообщения.
'[umka: ;13435845']если у вас были какие-то логические связи с каждой из этих записей в отдельности.
+150. Причём эти связи совсем не обязательно будут напрямую указаны в таблицах. Т.е. могут быть промежуточные таблицы и не факт что явно будут видны нужные связи.
Кто взламывает тот продаёт за приличные финансы это или юзает сам.
бла-бла-бла..
Ты говорили про решето. Подтвердишь свои слова делом (хотя бы ссылкой на успешный взлом. С описанием ессно - через что и как это произошло) или сольёшься как и все остальные балаблолки?
Мы не базаре и не за пивком.
Я всё больше убеждаюсь, что акк LEOnidUKG-а угнали.
Еще раз для упертых - ICANN не находится под управлением США.
Я тоже ещё год назад не мог и в страшном сне представить, что произойдёт..
И даже несколько дней назад не многие из этого топика - в участии в нём.
Я к тому, что это вопросу веры, не более.
Но началось всё не с этого, а с предложения некоторых съезжать с комов в рушки. На что я как бэ предложил подумать о целесообразности и разницы\последствий.
http://www.cvedetails.com/vulnerabil...Wordpress.html
И что? Я разве говорил, что в ВП не было и не будет никаких уязвимостей? Разве я когда-то отрицал, что они есть? Разве я говорил, что ВП - идеальная безопасная система?
Вопрос был такой:
Покажи когда последний раз был взломан ВП.
Можем сделать по- другому: я поставлю голый ВП. Кто взломает (в разумные сроки, разуется) - обещает подробно описать как был осуществлён взлом. Кто-то возьмётся? А то тыкать в опубликованные разработчиками (и пофиксенные) уязвимости дело не трудное. Вот воспользоваться ими - дело другое. :)
А что бы было легче пож: https://core.trac.wordpress.org/timeline
Ида, для сведения: версия 4.1 вышла 18.12.2014.
Вообще icann это международная организация и указы президента какой-либо страны, ее как-то волнуют мало
Чё, правда?
https://ru.wikipedia.org/wiki/ICANN:
...
Сегодня в ICANN проводится комплекс мер по выводу корпорации из-под контроля правительства США. [3]
...
Офисы ICANN расположены в Лос-Анджелесе, Брюсселе, Сиднее и Вашингтоне,
Перевести на доступный?
С IANA ещё интересней.
Но это, как я понимаю, не по теме этого топика.
Что то я вас не понял о Чебурашке...
Гуглить ICANN, IANA :)
Ну я понял к чему вы клоните
Мб. Но на всяк случай попробую пояснить.
Связи типа "многие-ко-многим" требуют промежуточную таблицу.
В самой базе может не быть видно прямых связей (зависимостей), а только в самом же движке жестко прописано какое поле в какой таблице нужно использовать.
Проще говоря по БД может не быть видно что значение в поле ID_metadata в таблице tbl_meta тоже самое, что и в поле ID_post в таблице tbl_content.
И это не самый сложный случай. Бывает, что к ИДшику поста "подязываются" данные из нескольких таблиц, при этом не по ИД поста, а через одно или несколько промежуточных данных.
Перекидывайте пока есть возможность
В чебурашке уже есть регистраторы?
Ну все таки один вопрос остается пока не решен это удаление дубликатов + ассинхронное удаление по айди из другой таблицы
Так ты же сказал:
Как бы я удалял сообщение не отслеживая связи ? или как бы движок удалял пост не отслеживая связи ? мол пост удалили а картинки которые идут в другой таблице под тем же айди удаленного поста оставим ? ну уж нет ну вообщем не в этом проблема щас.
Мне кацца, тебе надо как-то с этим определится :) В см со связями и отслеживанием оных.
вообщем об этом не беспокойтесь
Хорошо, не буду. :)
Вообщем есть, база, в ней есть 6к сообщение, из 6к сообщение наверно 1.5к дубли.
В базе не "сообщения", а "данные". "Сообщения" - в движке. Соответственно только движок может знать (а может и не знать) все связи этого сообщения.
;13435845']если у вас были какие-то логические связи с каждой из этих записей в отдельности.
+150. Причём эти связи совсем не обязательно будут напрямую указаны в таблицах. Т.е. могут быть промежуточные таблицы и не факт что явно будут видны нужные связи.