maragon

Ну, в теории WP движется в сторону FSE* чисто на родном редакторе, но до крутого билдера там как до луны на тракторе, хотя интересные моменты присутствуют. Можно глянуть плагины, которые новые блоки добавляют ну или написать самому под конкретную задачу (я писал, мне понравилось).

Хотя у Wordpress даже в этом случае получится бардак, т.к. любой плагин, имеющий стили и скрипты, будет их подключать и тянуть отдельно, что в теории может вызвать конфликты.

Я делал и самописные конструкторы страниц, и под Гутенберг писал кастомные блоки и как то однозначно сказать, что лучше - не могу, т.к. нужно понимать смысл задачи. В одном случае кастом wp просто идеально зашел, в другом случае нужно было прям по спецзаданию писать.

*FSE - full site editing, под этим разработчики имеют в виду то, что можно на Гутенберге собирать полностью сайт, вообще без кода (только по сути стили нужны).

RewriteEngine on

RewriteRule ^admin($|/) - [L]

RewriteRule ^$ index.php?module=page&url=main [L,QSA]
RewriteRule ^([^/]*)/?$ index.php?module=category&url=$1 [L,QSA]
RewriteRule ^([^/]*)/([^/]*)/?$ index.php?module=page&url=$1 [L,QSA]

Можно. Но реализовать это можно многими путями.
Вариант А.
Серверная часть (то бишь PHP) подготавливает как данные, так и графику.
Это значит, что вы на серверном скрипте как вычисляете все необходимые точки, так и рисуете график, например GD-библиотекой.
а) Создаете графическое полотно.
б) Рисуете в этом полотне необходимые линии.
в) Возможно, где-то что-то подписываете.
г) Отдаете клиентской части приложения (то бишь браузеру) бинарный поток файла изображения.
Самый топорный вариант, исследователь графика будет иметь на руках только картинку, ни смаштабировать, и изменить какие-нибудь атрибуты отображения он не сможет. Единственное преимущество - процесс вычисления графика доступен только вашему скрипту, и никто не сможет провести реверсинжиниринг, если захочет разобраться как вы его генерируете.
Вариант Б.
На стороне сервера делаете аналитику, отдаете браузеру готовый html-документ, содержащий canvas с генерированными на стороне сервера векторными объектами (линии графика) в svg формате. Это тоже топорный, но уже промежуточный вариант между А и В. Единственное преимущество - все данные векторные, поэтому они будут легковесны для передачи и воспроизведения в браузере.
Вариант В.
На стороне сервера делаете аналитику, отдаете данные о вычисленных точках клиенту в виде json, а на клиенте рисуете график в какой-нибудь js-библиотеке. Выбор библиотек широк: chart.js, D3.js и т.д.
Это самый прогрессивный вариант, поскольку на клиенте можно менять масштаб в окне просмотра графика, менять какие-нибудь атрибуты этого просмотра и т.д.

/(\d+)\s+\(\+(\d+)\)/

в ней нету формата изображения, можно конечно скачать прописав формат jpg ($newname = time() . '.jpg'), а вдруг там когда-нибудь будет png?

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

https://ru.stackoverflow.com/questions/825798/%D0%...

Ого наворотили то как!))) Почему просто одним запросом не получать нужный объект, а уже по надобности построения списка - обращаться к его свойствам?
Там я так понимаю вместо appenTo имелось ввиду appendTo наверно (2 раза)

UPD:
Ну на сервере берем массив в котором данные все в нужном формате, и возвращаем его:

$data = array("propName_1" => "value1", "propName_2" => "value2");
echo json_encode($data, JSON_FORCE_OBJECT);

Получить это все:

var jsonData = $.ajax({
	  url: "/api/backend/get_properties",
	  async: false
	 }).responseText;
	jsonData = $.parseJSON(jsonData);
	console.log(jsonData.propName_1); // value1

И вот у нас в глобальной области jsonData - все что надо. Берем и лепим... скульптуру))

class Hook {
  protected $callbacks;

  public function __construct($callbacks = []) {
    $this->callbacks = [];

    if (!isset($callbacks) || !is_array($callbacks) || sizeof($callbacks)) {
      return;
    }

    foreach ($callbacks as $k => $v) {
      if (!is_string($k) || !isset($v) || !is_callable($v)) {
        continue;
      }

      $this->callbacks[$k] = $v;
    }
  }

  public function add($key, $callback) {
    if (!isset($key) || !isset($callback) || !is_string($key) || !is_callable($callback)) {
      return;
    }

    $this->callbacks[$key] = $callback;
  }

  public function remove($key) {
    if ($this->exists($key)) {
      unset($this->callbacks[$key]);
    }
  }

  public function exists($key) {
    return isset($key) && array_key_exists($key, $this->callbacks);
  }

  public function run($key, ...$args) {
    if ($this->exists($key)) {
      $func = $this->callbacks[$key];

      if (!isset($args) || !is_array($args)) {
        $args = [];
      }
      
      if (isset($func)) {
        $func(...$args);
      }
    }
  }
}

$hook = new Hook();
$hook->add("my_hook", function ($args) {
  // todo
});

$hook->run("my_hook");
$hook->run("my_hook", 1, "string", true);

Что-то вроде такого?

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

Есть (по идее) две категории сущностей - сама организация, которая каталог предоставляет, и собственно предложения о продаже. Если выражаться в терминах schema.org, то первая сущность относится к Thing > Organization. У нее есть address, description, email, могут быть events, foundingDate, location, logo, telephone, image... и еще много всего, что эту организацию описывает. Сами предложения о продаже недвижимости более всего подходят к Thing > Intangible > Offer, а у оффера могут быть availability, availabilityEnds, availabilityStarts, category, offeredBy, price, priceCurrency, priceValidUntil, review, description, image и еще куча всего. Так что открывайте свой сайт, открывайте документацию, и прям по списку смотрите, какие свойства соответствующих сущностей есть у вас на страницах.

Смотреть в сторону Offer Schema и все что из этого раздела подойдет то и использовать

может, пригодится

В принципе, глубоко в код не лез, по беглому пробежался,
* немного напрягает наименования переменных и классов, я привык к camelCase, сегодня это в пыхе стандарт де-факто(хотя тут ща может вспыхнуть реальный холивар)
* классы обычно именуются с большой буквы,
* сегодня модно dependency injection, в этом ключе базовый класс не должен включать в себя бд, и знать в принципе не должен о существовании бд. При манипуляциях с данными по иерархи объектов нужно в бд передавать объект, и бд уже возвращает все что нужно(читай про di в гуглах).
* если все же базовый класс включает бд и все, то нахуа он Вам? Реализуй уже и CRUD хотя бы.
* Для удобства работы я бы рекомендовал еще отдельный класс коллекций объектов, очень помогает.
В остальном - каждый сходит с ума как ему нравится )