soka

В IPB есть такая штука как синхронизация пользователей (MemberSync), она выполняется при определенных событий on%Event% и имеет в своем классе большинство событий для полноценной синхронизации пользователя с удаленной базой данных - onCreateAccount, onLogin, onDelete, onProfileUpdate и тд. Этот инструмент дает больше возможностей для управления. Правда, с паролем там небольшие проблемы, так как есть только изменяемые поля, но нету "чистого" пароля. Можно и с методом авторизации синхронизировать, с костылями для хеширования пароля, регистрация аккаунта на примере выше это получилось так WoW External Auth.xml WoW External Auth.xml

Я и не собираюсь, этого еще мне хватало. Если бы мне нужно было им пользоваться я бы не стал его обсирать в качестве объективной критики. Автор темы/сообщения тоже меняется одним запросом, ну для обновления статистики и прочей херни можно дополнительно понаписать коду. Проверка пароля тоже делается одной строчки кода, да и не нужна она в принципе, лучше подключить ядро форума и проверять права администратора (только не говорите что вы искали и не нашли). ТС, вы же сами знаете что код унылый, и дело не в том что я могу написать лучше или хуже, или не нравится не пользуйся, а в том что это говнокод, пусть и для себя но который нужно писать нормально. Это уже прогресс. Критика пошла на пользу. Для будущего развития можно рассмотреть подобные варианты <?php require_once 'init.php'; \IPS\Dispatcher\Build::i(); foreach( \IPS\Db::i()->select('tid', 'forums_topics', array( 'topic_open_time > 0 AND topic_open_time <= ? AND approved = -1', time())) as $tid ) { $topic = \IPS\forums\Topic::load( $tid ); $topic->approved = 1; $topic->state = 'open'; $topic->topic_open_time = ; $topic->save(); $topic->resyncLastComment(); $topic->resyncLastReview(); if( $container = $topic->containerWrapper() ) { $container->setLastComment(); $container->setLastReview(); $container->save(); } } или одним sql запросом <?php require_once 'init.php'; \IPS\Dispatcher\Build::i(); \IPS\Db::i()->update( 'forums_topics', array('approved' => 1, 'state' => 'open', 'topic_open_time' => ), array( 'topic_open_time > 0 AND topic_open_time <= ? AND approved = -1', time() ) );

Нда, предыдущие работы полное уныние. По смене даты сообщения вообще не понимаю как можно было умудрится написать столько кода, да еще корявого, он меняется одним sql запросом с пару left join (запрос есть на ипбскинс). REST API для обновления темы POST /forums/topics/{id} locked=0 hidden=0

Темы создаются из PHP файла? Всю статистику и связи обновляете запросами? Апи форума для создания не рассматривали? Структура темы для постинга.

Ну вы же рассматривали наверное несколько вариантов перед созданием модификации - нативный код, плагин, крон сервера, крон форума. Прикидывали как лучше, какой способ легче, и выбрали один из них как самый оптимальный по времени создания и функциональности. Ведь наверняка в процессе создания некоторые аспекты пришлось рассмотреть, и наверное сделать по другому. Об этом хотелось бы услышать.

Вы используйте русскую локализацию на английский вариант базы данных. Для требуются два поле vk_uid и vk_token ALTER TABLE members ADD COLUMN vk_uid bigint(20) unsigned NOT NULL default '0', ADD COLUMN vk_token TEXT NULL

Интересует, но не код а способ его реализации и какие плюсы в выбранном методе.

Дич, но тогда перевод этого языка лэнга (word key: site) должно быть без закрывающих </a></li> Site</a></li> <li><a href='/' target='_blank'><i class='fa fa-question-circle'></i> Link

UPDATE profile_portal SET avatar_location=NULL, avatar_size=0, avatar_type=NULL, pp_main_photo='', pp_main_width=0, pp_main_height=0, pp_thumb_photo='', pp_thumb_width=0, pp_thumb_height='', pp_photo_type=''

Очевидно что темы не правильно были удалены. В бд темы состоят из двух главных таблиц - topics и posts. В первой таблице хранится информация о теме и ее название, во второй сами сообщения. Кроме этих двух дополнительно идут таблицы аттачей, опросов, кеша сообщений. Чтобы удалить тему, удалять как минимум нужно из таблиц topics и posts: DELETE t, p FROM topics t LEFT JOIN posts p ON p.topic_id=t.tid WHERE t.tid = ид темы Если из таблиц тем тема был удалена, нужно удалить сообщения из таблицы сообщений DELETE FROM posts WHERE topic_id = ид темы

Pages - приложение от IPS

Где ошибка? Где логи ошибки? Начать топик надо всегда с текстом ошибки, без него здесь делать нечего.

Удалить следующие лэнги. Но это костыль а не решение, не в этих, так в других может отвалится парсер если в переводе что-то изменится. Array ( [Russian (RU) - All Applications.xml] => Array ( [0] => coppa_form_intro [1] => coppa_form_phone [2] => coppa_form_date [3] => coppa_form_sig [4] => coppa_form_privacy [5] => coppa_form_mail [6] => coppa_form_fax [7] => delta_upgrade_download_full [8] => delta_upgrade_go_to_clientarea [9] => delta_upgrade_manual_footer [10] => theme_custom_setting_type [11] => theme_custom_setting_type_other [12] => editor_skin_nowrite [13] => htaccess_mod_rewrite [14] => task_method_cron_warning [15] => dashboard_tasks_web_broken_desc [16] => field_display_custom [17] => field_display_display_json_custom [18] => field_display_display_json_custom_desc [19] => field_display_listing_json_badge [20] => field_display_listing_json_custom [21] => field_display_listing_json_custom_desc [22] => cms_field_no_type_warning [23] => invoice_timeline_generate_event [24] => invoice_timeline_generate_time [25] => invoice_timeline_invoice_exp_time [26] => err_no_shipping_methods [27] => f_blurb_maxmind_riskyemail_y [28] => p_stock_price_dynamic_desc [29] => easypost_address_default_desc ) [Russian (RU) - Commerce.xml] => Array ( [0] => paymethod_countries_desc [1] => invoice_timeline_grace_time [2] => invoice_timeline_grace_event [3] => invoice_timeline_invoice_exp_event [4] => fraud_rule_conflict [5] => p_stock_price_dynamic_desc [6] => email_transaction_waiting [7] => task__billingAgreements ) [Russian (RU) - Pages.xml] => Array ( [0] => field_display_display_json_custom [1] => field_display_display_json_custom_desc [2] => field_display_listing_json_custom_desc [3] => cms_field_no_type_warning [4] => field_display_opts_title [5] => field_display_opts_content ) [Russian (RU) - System.xml] => Array ( [0] => delta_upgrade_manual_footer [1] => delta_upgrade_mismatch_versions [2] => no_phar_extension [3] => gbw_delete_attachments [4] => gbw_delete_attachments_desc [5] => captcha_type_recaptcha2 [6] => editor_plugin_folder [7] => editor_plugin_folder_desc [8] => htaccess_mod_rewrite [9] => htaccess_mod_rewrite_desc [10] => plugin_settings_keys [11] => plugin_settings_code [12] => plugin_settings_code_desc [13] => dashboard_tasks_not_enough_desc ) )

Достаточно это сколько? Два дня?

https://en.wikipedia.org/wiki/Unicode_and_email#Unicode_support_in_message_header Кодирование заголовка трогать нельзя. Настройка которая носит в себе потенциальный баг не должна быть ни опционально, ни в отключенном виде по умолчанию. Если хочется угодить spamassasin'у с его непонятной логикой в правиле "FROM EXCESS BASE64" используйте условие на "non-ASCII" символы, которое, кстати, в этом же месте используется чуть ниже с помощью регулярного выражение. Из функций можно использовать mb_check_encoding. $this->headers['From'] = ( $this->fromName ) ? ( !mb_check_encoding( $this->fromName, 'ASCII' ) ? '=?UTF-8?B?' . base64_encode( $this->fromName ) . "?= <{$this->from}>" : $this->fromName . " <{$this->from}>" ) : "<{$this->from}>"; Но в php есть специальная функция для кодирования email заголовка в случае если он не соответствует требованиям RFC. Она тоже используется в коде для кодирования заголовков, поэтому не понятно почему IPS заговнокодили здесь ручным кодированием. $this->headers['From'] = ( $this->fromName ) ? ( mb_encode_mimeheader( $this->fromName ) . " <{$this->from}>" ) : "<{$this->from}>";

{$l2cfg["forum"]["prefix"]}topics заменить на {$l2cfg["forum"]["prefix"]}forums_topics

Некрофилы, хватит использовать использовать CGI. Это устаревший протокол заре интернета у которого низкая производительность и проблемы с безопасностью. Никакое отношение через какой интерфейс работает php к этой проблеме не имеет. XMLReader аналогично дает сбой и на apache2handler при том, что simplexml разбирает файл без ошибок. ТС, пишите баг репорт или даунгрейдите версию php.

Это не трактовка RFC, и никаких "моих" я не давал, это аналог "принудительного приведения типа". В нее нет необходимости потому что она как минимум бесполезна. Это не более чем ваша очередная фантазия на тему, что имеет значение закодированная строка в заголовке "чистый" ASCII или utf-8. Кстати, а тесты проводились на двух закодированных строк в разных кодировках? Может быть фильтр был настроен таким образом, чтобы он просто срабатывал на кодированную строку в From. Spamassassin это ПО с набором правил, его результат во многом зависит от того, каким образом он был настроен и сколько "баллов" указанно для того или иного правило. Что действительно реально играет роль для спамфильтра это подписи DKIM и SPF.

Пишите тогда багрепорт разработчикам. У вменяемых сервисов с этим проблем нету. По хорошему возможно и надо было, хотя лично я считаю что это не обязательно - в данном случае работает правило "принудительного кодирования", но у вас также никакой проверки нету, а вот не закодированной заголовок в utf-8 действительно является ошибкой которая может доставить неприятности, учитывая то, что у 90% пользователей русского пространство название форума содержит кириллицу. Изменение в этом случае не только бесполезное, но еще и вредное, тем более что вы советуете его и другим пользователям.

Нет никакого излишнего кодирования заголовков. Согласно RFC, символы из не диапазона ASCII должны кодироваться. Отсутствия кодирования в заголовке From как минимум приведет к крокозябрам в поле отправителя, а в худшем случае может нарушить структуру заголовка.

IPB_Firewall это вирус которым заражали тройку. Откройте conf_global.php и удалите этот класс, там должны остаться только настройки форума.

То же самое я могу сказать о вас. Но ведь этого не говорю, потому что мне не известен уровень ваших знаний, интересно каким образом вы определили мой чтобы называть меня профаном? Пока я могу сказать, что вы явно не хотите слушать и упорно пытаетесь доказать свой тезис с пеной у рта, не обращая никакого внимания на реальные доводы которые вам приводят, будто не дай бог это окажется правдой. Ясно, на словах вас не переубедить и никакой информации не донести, тут явный блок - "профан что-то мне втирает". Не хотите слушать, ваше дело, проверьте тогда сами свои утверждения, докажите несостоятельность моих, и не ссылкой на какой-то код в котором вы не разбираетесь. Проведите опыты - скачайте лэнгпак и попробуйте прочитать файлы xmlreader'ом. Отключите вывод ошибок из libxml_use_internal_errors и попробуйте снова. Мне ничего доказывать не нужно, докажите себе.

Как вы там говорили - вы можете предполагать что угодно, на деле же все обстоит иначе. Зачем вы мне втираете эту дичь, возьмите, напишите пару строчек кода и проверьте. Для документации незачем лазить в эту степь, достаточно посмотреть описание метода read() http://php.net/manual/ru/xmlreader.read.php и возвращаемого значения - FALSE в случае ошибки. http://php.net/manual/ru/xmlreader.read.php#114248 Вы спорите не предположениях что не может, а вам приводят доводы на практике и результате такого костыля - язык не импортируется (скорее всего только частично если посмотреть в бд). С каких пор варнинги не могут прекратить работу какой-то функции?

http://ipbmafia.ru/topic/10597-ru4-urls-transliteration/?page=3#comment-102184

Я сейчас не о ips говорю. Вы подавляете ошибку чтобы не прекратить работу форума выбросом варнинга, но xmlreader все равно не будет дальше разбирать документ и импорт каждого файла закончится до первой ошибки в нем. О чем ТС и говорит, что перевод у него не полный.