We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 33694
    • 742 Posts
    Просто, то оно просто, но не вникая в подробности работы с базами (я в этом профан) могу сразу заметить, что трудности появятся при работе с вшеншими файлами: картинки в новость пользователь захочет добавит, прайслист обновить. Как это реализовать?
    В самом простом случае, на мой взгляд, нужно будет синхронизировать по ftp определённые (заданные) дирректории. Но как узнать, когда это нужно делать, а когда нет? Хотя, тут можно свалить всё на пользователя добавив необходимую кнопку, типа ReUploadFiles.

    Вот блин, оказывется ничего особо сложно всё таки нет.
      • 26734
      • 23 Posts
      Вы чего с толку сбиваете?...
      И в мыслях даже не было!!! Честное благородное слово! Просто, чтобы не смущать публику, задача сначала была выдана в урезанном виде. И этого хватило чтобы начать обсуждалово, за что всем весьма признателен.
      Итак, задачка:
      1. сайты на локале и в сети имеют одинаковую структуру таблиц в базе и каталогов на диске;
      2. изменение контента ведется с нескольких рабочих мест на локалях и подразумевает под собой изменение текстовых блоков, аплоад картинок, аплоад файлов, которых можно скачать посетителю сайта;
      3. поскольку все хотелось бы осуществлять средствами, интегрированными в MODX, пользователь бэкэнда должен иметь управляющий элемент (либо - несколько) + настройки, которые позволят ему привести в соответствие содержимое локальной версии сайта и интернет-версии.

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

      Я не сильно напрягаю уважаемое сообщество?
        • 26734
        • 23 Posts
        À âîîáùå, ìîæíî íà÷àòü ñ áîëåå ãðàìîòíîé è ïîëíîé ïîñòàíîâêè çàäà÷è. ÒÇ, òàê ñêàçàòü, âûðàáîòàòü.
          • 31213
          • 153 Posts
          [e]Bu$ter Файлы видно по их путям в теле документа и расширениям. Регуляркой находим все, что теоретически может быть файлом, затем проверяем на существование собственно такого файла. Получаем чистый массив всех файлов, которые есть. Смотрим их размер и запоминаем.
          После того, как контент-менеджер поменял что-либо, быстро проверяем снова все измененные документы - у них в таблице site_content поменялся editedon, смотрим на файлы. Снова проверяем на существование, запоминаем размер.
          Теперь сличаем массив файлов до изменений и после. Отсекаем те, у которых размер не изменился (это касается только бинарных файлов, не текстовых) и заливаем все на сервер.

          ИМХО, геморой полнейший.
          Легче сделать отдельный бэкэнд на сервере, чем так трахаться
          В прочем, флаг вам в руки!
            • 33694
            • 742 Posts
            Vadya corp., так я и написал там — в простейшем случае. Описанный тобой подход — это обыкновенный случай, он тоже рассмативался wink Потому то я и заговорил о том, что с файлами будут сложности.

            > В прочем, флаг вам в руки!
            Я что-то пропустил, кто-то уже собрался разрабатывать сей агригат?
              • 31213
              • 153 Posts
              [e]Bu$ter Я имел ввиду, что лично я разрабатывать его не хочу, т.к. по моему мнению, эта задумка слишком плохая (в смысле, чтобы делать на локале, а потом синхронизировать), чтобы ее реализовывать.
                • 26586
                • 184 Posts
                Quote from: Vadya at Jul 27, 2007, 07:02 PM

                [e]Bu$ter Файлы видно по их путям в теле документа и расширениям. Регуляркой находим все, что теоретически может быть файлом, затем проверяем на существование собственно такого файла. Получаем чистый массив всех файлов, которые есть. Смотрим их размер и запоминаем.
                После того, как контент-менеджер поменял что-либо, быстро проверяем снова все измененные документы - у них в таблице site_content поменялся editedon, смотрим на файлы. Снова проверяем на существование, запоминаем размер.
                Теперь сличаем массив файлов до изменений и после. Отсекаем те, у которых размер не изменился (это касается только бинарных файлов, не текстовых) и заливаем все на сервер.

                ну зачем так сложно?

                Локальный сайт правится и является актуальным всегда, значит...
                1 база заливается на сервер как sql
                2 все локальные файлы которых нет на сервер заливаются
                3 все локальные файлы у которых не совпадает размер или дата изменения заливаются на сервер
                4 стирается база на сервере и исполняется sql
                5 стираются все файлы которых нет локально
                (базу можно лить не всю, а только контент, настройки и пр.)