47911

Вообщем, оказывается: дебиан 12 из коробки и Лебиан 11 из коробки, после установки, настройки сети из DHCP автоматом настраивает. А надо было насильно вручную прописывать(даже если на стадии установки, в 11 версии ставить вручную - после установки всёравно оставляет настройки "автоматом DHCP".)

По некоторым причинам(из-за требования к более низкой версии Мускула) установлен 11. И после ручной настройки шлюза с маской - интернет есть. А если ручками настраивать в /etc/network/interface(не точный путь, по памяти пишу) - даже после перезагрузки он настройки не принимал\активировал.

Вообщем, как сказал Alexey Dmitriev - теория важна. Но у меня - горело: ССД подгорел. Поэтому не до "учёбы".

В общем. Спустя сутки(как я понял) проблема исчезла. Видимо носит временный характер.

Вообщем. Это был блокировщик рекламы. Судя по тому факту, что: после его отключения начала вылезать реклама от ria-новости(кучи статей, ну вы такое встречали) - я попал в удивительный мир переизбитка рекламы...

Вопрос: как найти это у себя?

Его вывод:

<div style="position: relative; background-color: rgb(252, 252, 252); display: flex; max-width: 400px; margin: 20px auto; width: 100%; clear: both;" id="large-r-628144">
  <iframe id="ilarge-fr-240721" scrolling="no" style="border: 0px none; max-width: 400px; box-sizing: border-box; width: 100%; height: 355px;" width="1280" height="0"></iframe>
  <div id="medium-blocks-wrapper" style="display:flex; flex-direction: column; width:100%">
    <iframe id="ilarge-fr-531361" scrolling="no" style="border: 0px none; box-sizing: border-box; width: 100%; height: 110px;" width="1280" height="0"></iframe>
    <iframe id="ilarge-fr-274353" scrolling="no" style="border: 0px none; box-sizing: border-box; width: 100%; height: 110px;" width="1280" height="0"></iframe>
    <iframe id="ilarge-fr-767554" scrolling="no" style="border: 0px none; box-sizing: border-box; width: 100%; height: 110px;" width="1280" height="0"></iframe>
  </div>
</div>

сам модуль, который это выводит, нормально выглядет(код).

Я так понимаю: в ядро надо лезть искать?

*Щас подумал: поверх разархивировать чистую джумлу. Щас буду пробовать.

Так. Частично вопрос решился:
копирую в Notepad++, там делаю замену по принципу ", " на "новую строку и табуляцию", вставляю в эксель - осталось понять: как заполнить пустые строки.

Т.е. щас выглядет:
Название1 = email1
Название2 = email1
= email2
Название3 = email1
= email2
= email3

где "=" это в экселе отделение "колонки1" от "колонки2"(если кто не понял)
Как автоматом прописать "Название3 1" и "Название3 2" и т.д. ? Т.е. заполнить пустые ячейки с лева от email?

Дополнение:
Вообщем: делим столбец по "Данные -> текст по столбцам". Далее вставляем с лева столбец перед каждым значением. Копируем в эти столбцы название 1 к 1.
Получается:
Столбец1 = Столбец2 = Столбец3 = Столбец4 = Столбец5 = Столбец6
Название3 = email1 = Название3 = email2 = Название3 = email3

Делаем таблицу. Копируем 1 столбец и 2 столбец в блокнот, затем сортируем по 4 столбцу "те строки, где есть текст(подразумевая email)" - копируем в блокнот 3 и 4 стобец.(после 1-й вставки). И т.д. Получаем нужный результат.
Вставляем из блокнота в Excel. Не забыв перед этим выбрать в "Текст по столбцам" разделитель - табуляция, чтобы по колонкам снова начал разбивать по табуляции. Emails у меня были через ", " - для разбивки на колонки надо было менять с табуляции на ",".

Что-то более автоматическое я не придумал. Но надо такое делать не часто. 1 раз в месяц.

Вообщем. Проблема была в оперативе(одна из 16-и плашек глючила).

тынц

edac-util -v

И немного подробнее: в IPMI есть логи, в которых подобная инфа вылезает, если что не так. Собственно - вынули и всё в порядке.

Если в кратце: Dr.Web блокировал. Хотя я добавлял в исключения.
Добавил сам файл - заработало.

Вообщем. компонент Query Monitor дал наводку "медленный запрос к таблице wp_options", и в ней есть "option_name = cron" и у него самое большое значение. Т.е. основной вес таблицы(у которой, я не обращал внимание 40 мб. веса). Я думаю не надо разжовывать проблему.

Решение:
в поле "логин" вписывался email. Т.е. символ "@" вызывал проблему. Если его убирать - всё в порядке.(сам компонент почему-то не убирал.)

Также в Joomla 4 появилась статья "#__workflow_associations", собственно её тоже надо заполнять.

Можно не заполнять "#__assets" - статьи видно.

Решение:
в /modules/mod_finder/tmpl/default.php
есть строка:

$input = '<input type="text" name="q" id="mod-finder-searchword' . $module->id . '" class="js-finder-search-query form-control" value="' . htmlspecialchars($app->input->get('q', '', 'string'), ENT_COMPAT, 'UTF-8') . '"' . ' placeholder="' . Text::_('MOD_FINDER_SEARCH_VALUE') . '">';

Меняем её на:

$input = '<input type="text" name="q" id="mod-finder-searchword' . $module->id . '" class="js-finder-search-query form-control" value="' . '"' . ' placeholder="' . Text::_('MOD_FINDER_SEARCH_VALUE') . '">';

Т.е. value = "", чтобы избавиться от проблемы.

Оказывается "предоставитель услуг" заблокировал его(25-й порт).. Собственно вопрос к нему.

Если кому интересно, решил так:
Создал "характеристики" товара: Склад1, Склад2, выпадающее поле с "Склад1, Склад2". При заказе в функции "confirmedOrder"(в файлах магазина) дописал "обновление базы данных на основе выбранного в 'выпадающее поле' при заказе товара".

Решение проблемы с поиском. Несмотря на сказанное: SimpleSearch может искать и в магазине miniShop2.

И да: сайт недоделан.

Решение найдено.
Есть таблицы:
#__community_notifications
#__community_activities
#__community_groups_discuss
#__community_mailq
В них есть поля, куда записывается информация об обсуждении(напомню: компонент JomSocial, в обсуждение пытаюсь запихнуть текст длинной более 65535) - выдаётся ошибка, т.к. в одной или более таблице есть поля с "длинной поля" до 65535 символов - возникает ошибка. Нужно изменить длинну поля на большее(Тип поля: mediumtext - спасибо Сергей delphinpro, Дмитрий вы были правы. Просто не в 1-о место записываются данные). Название полей не даю т.к.: если вы сами не можете разобраться - лучше не лезте туда сами.

Daria Motorina
https://serverfault.com/a/782128/441975

После указания:
opcache.memory_consumption = 128
(раскоментировал)
Импорт прошёл, видимо глючил кешер.

Обновлено: 18.03.2021
Я поторопился. Проблема никуда не ушла.
Но: 1-й запуск за сутки - позволяет импортировать. А вот последующий импорт - не доходит до конца.

Если важно: php-fpm 5.6, php-fpm 7.0, php-fpm 7.3, php-fpm 7.4(на выбор)
Скрипт запускается на php-fpm 7.4
mariadb Ver 15.1 Distrib 10.5.9-MariaDB
100 гигов оперативки
2 проца по 16 ядер 2.40GHz
И загрузка не превышает 50% проца и 70% памяти.
использую в скрипте:
mysqli_autocommit и mysqli_commit

Есть идеи? Импортирую по факту 100 000 статей, в 5 таблиц(количество таблиц к которым обращаюсь), и в одну из них - 15-20 записей(свойства). Итого 20-25 запросов максимум. И оно выпадает с:

[error] recv() failed (104: Connection reset by peer) while reading response header from upstream

Я уже не знаю что ещё пробовать. В теории будет ещё импорт с большим количеством записей, неужели делить по 10 000 ? Ещё идеи есть?

Обновлено
проблема была решена. Надо запускать под админом, в консоле. Тут нету прерывания.

В "Типах статей" надо выбрать "список полей" у текущего типа. В поле, в настройках: "Использовать для фильтрации" - да. По умолчанию стоит НЕТ, и не для всех полей оно возможно.

И оно магическим образом заработало, само(я единственное что сделал: расставил в коде импорта метки вида "открыть файл - записать - закрыть", чтобы увидеть где он там спотыкается. И оно заработало само.).

Судя по всему всётаки было с ними всё в порядке.

База грузила все 32 ядра процессора. Поэтому начал грешить на "посещяемость".
====
Вообщем. Проблема была в оперативе(одна из 16-и плашек глючила).

https://debianforum.ru/index.php/topic,16064.0.htm...

edac-util -v

И немного подробнее: в IPMI есть логи, в которых подобная инфа вылезает, если что не так. Собственно - вынули и всё в порядке.