SeVlad

SeVlad
Рейтинг
1609
Регистрация
03.11.2008
llppzz:
Еще раз для упертых - ICANN не находится под управлением США.

Я тоже ещё год назад не мог и в страшном сне представить, что произойдёт..

И даже несколько дней назад не многие из этого топика - в участии в нём.

Я к тому, что это вопросу веры, не более.

Но началось всё не с этого, а с предложения некоторых съезжать с комов в рушки. На что я как бэ предложил подумать о целесообразности и разницы\последствий.

Оптимизайка:
http://www.cvedetails.com/vulnerabil...Wordpress.html

И что? Я разве говорил, что в ВП не было и не будет никаких уязвимостей? Разве я когда-то отрицал, что они есть? Разве я говорил, что ВП - идеальная безопасная система?

Вопрос был такой:

SeVlad:
Покажи когда последний раз был взломан ВП.

Можем сделать по- другому: я поставлю голый ВП. Кто взломает (в разумные сроки, разуется) - обещает подробно описать как был осуществлён взлом. Кто-то возьмётся? А то тыкать в опубликованные разработчиками (и пофиксенные) уязвимости дело не трудное. Вот воспользоваться ими - дело другое. :)

А что бы было легче пож: https://core.trac.wordpress.org/timeline

Ида, для сведения: версия 4.1 вышла 18.12.2014.

llppzz:
Вообще icann это международная организация и указы президента какой-либо страны, ее как-то волнуют мало

Чё, правда?

https://ru.wikipedia.org/wiki/ICANN:

ICANN (читается айкэ́н[1]) — международная некоммерческая организация, созданная 18 сентября 1998 года при участии правительства США
...
Сегодня в ICANN проводится комплекс мер по выводу корпорации из-под контроля правительства США. [3]
...
Офисы ICANN расположены в Лос-Анджелесе, Брюсселе, Сиднее и Вашингтоне,

Перевести на доступный?

С IANA ещё интересней.

Но это, как я понимаю, не по теме этого топика.

Maxim-KL:
Что то я вас не понял о Чебурашке...

Гуглить ICANN, IANA :)

nomarketing:
Ну я понял к чему вы клоните

Мб. Но на всяк случай попробую пояснить.

Связи типа "многие-ко-многим" требуют промежуточную таблицу.

В самой базе может не быть видно прямых связей (зависимостей), а только в самом же движке жестко прописано какое поле в какой таблице нужно использовать.

Проще говоря по БД может не быть видно что значение в поле ID_metadata в таблице tbl_meta тоже самое, что и в поле ID_post в таблице tbl_content.

И это не самый сложный случай. Бывает, что к ИДшику поста "подязываются" данные из нескольких таблиц, при этом не по ИД поста, а через одно или несколько промежуточных данных.

Maxim-KL:
Перекидывайте пока есть возможность

В чебурашке уже есть регистраторы?

nomarketing:
Ну все таки один вопрос остается пока не решен это удаление дубликатов + ассинхронное удаление по айди из другой таблицы

Так ты же сказал:

nomarketing:
Как бы я удалял сообщение не отслеживая связи ? или как бы движок удалял пост не отслеживая связи ? мол пост удалили а картинки которые идут в другой таблице под тем же айди удаленного поста оставим ? ну уж нет ну вообщем не в этом проблема щас.

Мне кацца, тебе надо как-то с этим определится :) В см со связями и отслеживанием оных.

nomarketing:
вообщем об этом не беспокойтесь

Хорошо, не буду. :)

nomarketing:
Вообщем есть, база, в ней есть 6к сообщение, из 6к сообщение наверно 1.5к дубли.

В базе не "сообщения", а "данные". "Сообщения" - в движке. Соответственно только движок может знать (а может и не знать) все связи этого сообщения.

'[umka:
;13435845']если у вас были какие-то логические связи с каждой из этих записей в отдельности.

+150. Причём эти связи совсем не обязательно будут напрямую указаны в таблицах. Т.е. могут быть промежуточные таблицы и не факт что явно будут видны нужные связи.

obzor, я-то тут причем?

Всего: 28523