Михаил Ливач

detectmobilebrowsers.com

Правильнее так:

Type.js

class Type
{
    isArray() {}
}

export default Type

Dialog.js

class Dialog 
{
    show() {}
}

export default Dialog

CRM.js

import Type from './Type.js'
import Dialog from './Dialog.js'

export { Type, Dialog }

И далее исходный код скармливается сборщикам типа babel, gulp, rollup и прочим. И вот то, что вы привели - результат работы с кодом этих сборщиков для совместимости со старыми браузерами. Для ноды само собой сборщики не используются - там они не нужны. Простой пример реализации библиотеки для ноды/браузера с использованием сборщиков rollup и babel: @voidvolker/enum.

Оборачиваем всё в транзакцию, да и всё. И тогда создадутся либо обе записи, либо ни одной. Так мы не расплодим сироток в случае ошибочных данных.

Модели:

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;

class User extends Authenticatable
{
    use HasFactory, Notifiable;

    /**
     * @var array<int, string>
     */
    protected $fillable = [
        'name',
        'email',
        'password',
    ];

    /**
     * Получить данные пользователя, связанные с этим пользователем.
     */
    public function userData()
    {
        return $this->hasOne(UserData::class);
    }
}

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Database\Eloquent\Model;

class UserData extends Model
{
    use HasFactory;

    /**
     * @var array<int, string>
     */
    protected $fillable = [
        'phone_number',
    ];

    /**
     * Получить пользователя, которому принадлежат эти данные.
     */
    public function user()
    {
        return $this->belongsTo(User::class);
    }
}

Создание записей

use App\Models\User;
use App\Models\UserData;
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Hash;

DB::transaction(function () {
    // 1. Создаем пользователя (User)
    $user = User::create([
        'name' => 'Вася Пупкин',
        'email' => 'uasya@fsb.ru',
        'password' => Hash::make('12345'),
    ]);

    // 2. Создаем данные пользователя (UserData) и связываем их с пользователем
    $user->userData()->create([
        'phone_number' => '112',
    ]);
});

P.S. ИМХО: ненавижу Eloquent и весь паттерн Active Record. Как по мне, вместо него лучше уж просто чистым SQL пользоваться. А вот если нужна мощная ORM, то уж лучше воспользоваться Doctrine. Там вообще такой проблемы нет, и всё делается автоматически.

// Предотвращаем стандартную отправку формы

Надо установить ему https://developer.mozilla.org/en-US/docs/Web/CSS/p... none, а активным элементам на нем - в auto

private string $requestUri = '/';
...
if ($this->requestUri !== '/') {

То есть, при инициализации экземпляра вы записываете в requestUri слэш, а перезаписываете значение только если там не слэш. Соответственно, условие всегда ложно и тело условия не выполняется.

После отключения бустов, разгона процессора, C6, в BIOS, идущих по умолчанию система вновь начала работать стабильно.

Ячейки флешки это конденсаторы. С течением времени они разряжаются. Тем более на дешманкитае типа Smartbuy. Кстати на это мог повлиять нагрев, вспомните, не перегревался ли телефон в ближайшее время

Очень странно, что данные вообще читаются, там как бы контрольные суммы и всё такое, обычно просто ошибка чтения и всё. Никаких битых файлов. Но видимо настолько дешманкитай

Забэкапить важные данные и заменить флешку на что-то менее непотребное типа Samsung, WD (бывший SanDisk), ну хотя бы Transcend

Как только повреждения затронут прошивку флешки, она перейдет в read only или перестанет определяться.

Нужно «настоящий» сервер описать отдельно, а всё остальное пусть редиректит в него.

Примерно так:

server {
    listen 443 ssl;
    server_name toorrp4.fvds.ru;

    # тут конфигурация сервера
}

# а тут редиректим всё остальное
server {
    listen 443 default_server ssl;
    return 301 https://toorrp4.fvds.ru$request_uri;
}

test += 10;

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

Ну вот вам генерация арифметической прогрессии:

function* arithmeticSequence(a1, d, length = Infinity) {
  for (let i = 0; i < length; i++) {
    yield a1 + i * d;
  }
}

Как использовать:

const t = arithmeticSequence(10, 10);
t.next().value // 10
t.next().value // 20
t.next().value // 30
// ну и т.д., вызываем столько раз, сколько значений нужно получить

for (const n of arithmeticSequence(1, 23)) {
  if (n > 100) {
    break;
  }

  console.log(n); // будет выведено: 1 24 47 70 93
}

[...arithmeticSequence(3, 4, 5)] // получим следующий массив: [3, 7, 11, 15, 19]

[...arithmeticSequence(1, 1)] // шутка, так не надо

К сожалению, без хака тут не обойтись. Но если получен результат, то кому какое дело? Берем волшебную палочку и достаём кролика из шапки. Сплошная иллюзия и никакого мошенничества.

- $this->getRootCategory($data[0]['parent_id']);
+ return $this->getRootCategory($data[0]['parent_id']);

Скорее всего дело в сессии. Попробуйте вставить вызов session_write_close() непосредственно перед выводом файла:

header('Pragma: private');
header('Expires: Mon, 26 Jul 1997 05:00:00 GMT');
header('Content-Length: ' .filesize($file));
session_write_close(); // <--- вот здесь         
readfile($file);
exit();

Имеет смысл делать обновление, если все работает нормально?

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

В первую очередь надо смотреть на то, когда заканчивается поддержка у той или иной технологии. И у PHP 7.4 она закончилась ещё в 2022 году.

Это означает, что дыры в безопасности уже никто чинить не будет. А там их немало. И сайт будет всё проще и проще взломать с каждым новым днём.

Возможно, ваш хостер имеет возможность внедрять патчи расширенной поддержки от Zend, которые так же закончатся уже в 2026 году.

Поэтому, обновить стоит. Но перед этим надо убедиться в работоспособности сайта с этой версией.

1. Полный бэкап файлов и базы. Это даже не обсуждается. Если у хостера бэкап не купили, купите.

2. Обновите всё, что сможете до последних версий. Разработчики часто добавляют совместимость для новых версий PHP в эти последние версии. Это касается и ядра WordPress, и плагинов, и темы, если она была куплена, а не писалась с нуля. Если тему писали с нуля, то можно связаться с разработчиком, чтобы он дал вам точный ответ, будет ли тема работать, или сделал бы поддержку 8.3

3. После обновления плагинов и тем проверьте в их документации совместимость этих обновленных версий с PHP 8.3.

4. Используйте плагин проверки совместимости, чтобы узнать, будет ли ваш сайт работать на 8-х версиях PHP. Он старый, но именно с этой задачей поможет справиться. https://wordpress.org/plugins/php-compatibility-ch...

5. Самым идеальным вариантом проверки всего этого дела было бы купить у хостера на месяц такой же хостинг и там опробовать сайт на новой версии. Это закроет все галочки в вашем списке сомнений. Если нет возможности этого сделать, то хотя бы на локальной машине запустите сайт на новом PHP. Можно ещё и дебаг-режим включить, чтобы иметь полный расклад в логах.

6. Если всё это сделали, можно пробовать менять версию PHP на основном хостинге. Делать это лучше когда посетителей меньше всего, но поддержка хостера ещё не спит. Если не сработает, то верните всё из бэкапа.

7. Далее вам нужно наблюдать за работоспособностью и стараться периодически обновлять ядро и плагины, чтобы следующий апгрейд прошел более гладко. Если вы всё-таки решили купить второй хостинг на 5 шаге, то вы можете его даже и оставить как раз для целей проверки обновлений и каких-то новых фич. Не забудьте его тогда закрыть от роботов на всякий случай, чтобы предотвратить индексирование поисковиками.

Можно сразу передавать данные в цикл:

docker image ls --format "{{.Repository}} {{.Tag}}" | while read image tag; do
  echo "image: $image"
  echo "tag: $tag"
done

В принципе можно просто сохранить в переменную и потом использовать её, точно так же:

images=$(docker image ls --format "{{.Repository}} {{.Tag}}")
echo "$images" | while read image tag; do
  echo "image: $image"
  echo "tag: $tag"
done