SS7 и загрузка файлов через IframeTransport Архив

17 комментариев

• популярные
• новые
• старые

• +2

  Syrnik.com 20 мая 2016 18:20 #

  Проблема с водяным знаком видимо из этой же оперы :)

  • +1

    ITFrogs 20 мая 2016 18:23 #

    Как раз в водяном знаке я эту методику загрузки файлов и подсмотрел.

  • +1

    Владислав Горлов 20 мая 2016 18:39 #

    Добавлена строгая проверка на тип элемента настроек и если он отличается от waHtmlControl::FILE, то файлы игнорировались.

    Это, собственно, и ломает плагины, где используется собственная реализация настроек без описания их в lib/config/settings.php
    

    • +1

      ITFrogs 20 мая 2016 18:44 #

      Т.е. сейчас обязательно прописывать в lib/config/settings.php или можно подсмотреть как у вас автоматом генерится инпут и сделать четко как у вас? Там же помимо самого файла еще яваскрипт чтобы показать его сразу же после загрузки.
      

    • +2

      Syrnik.com 20 мая 2016 18:50 #

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

    • +1

      ITFrogs 20 мая 2016 18:58 #

      Сейчас написал в settings.php

          'test_file' => array(
              'title'         => _wp('Test file'),
              'value'         => '',
              'control_type'  => waHtmlControl::FILE,
              'subject'       => 'basic_settings'
          ),

      Сохранил картинку. В результате нет никакого отклика для юзера что файл загружен.

      

      Если мы в настройках пишем

      'control_type'  => 'text',

      То после сохранения мы видим тот же текст. А тут как-то глухо. Я понимаю что можно превьюшку под это вывести отдельной настройкой, но получается, что для каждого файла нужно использовать два пункта в меню настроек?
      

    • +1

      ITFrogs 20 мая 2016 19:05 #

      Проверил. Все равно файл в $settings не попадает

      Даже если

      'control_type'  => waHtmlControl::FILE,

      
      

    • +1

      ITFrogs 20 мая 2016 19:23 #

      Тестирую дальше.
      

      В плагине можно получить список загруженных файлов через

      waRequest::file('shop_myplugin');

      В $settings эти файлы больше не попадают. и абсолютно пофиг на строгое соответствие. Любой инпут типа файл видно только через waRequest::file

      
      
• +2

  ITFrogs 20 мая 2016 19:09 #

  Во. Придумал. Вы watermark почините пожалуйста, а я там посмотрю как правильно. А вы, пока чинить будете, поймете, что где-то ошибку допустили и пофиксите движок.
  

• +2

  ITFrogs 20 мая 2016 20:26 #

  Мы с Сергеем Родовниченко локализовали баг.

  Смотрим файл waPlugins.actions.php метод saveAction(), видим код

  $files = waRequest::file($namespace);
  $settings_definitions = $plugin->getSettings();
  foreach ($files as $name => $file) {
      if (isset($settings_definitions[$name])
          && !empty($settings_definitions[$name]['control_type'])
          && ($settings_definitions[$name]['control_type'] == waHtmlControl::FILE)
      ) {
          $settings[$name] = $file;
      }
  }

  Вся беда в том, что $plugin->getSettings() возвращает только значения. ['control_type'] там по определению быть не может.

  

  Соответственно условие не срабатывает никогда.
  

• +1

  ITFrogs 20 мая 2016 20:37 #

  А вообще это условие конечно приучает к порядку, но сильно ограничивает функциональность.

  Вы не подумали о возможности загружать произвольное количество файлов.

  Допустим у меня сейчас в разработке плагин, где пользователь загружает в одной настройке несколько файлов сразу. Заранее не известно сколько. Я ж не буду под каждый файл в settings.php добавлять значения. Придется костылировать, что не есть хорошо.

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

  Мы то все равно найдем пути обхода. Только вот зачем вынуждать нас это делать?..
  

  • +1

    Алексей 21 мая 2016 02:08 #

    Всегда есть возможность использовать custom_settings

    • +1

      ITFrogs 21 мая 2016 04:01 #

      Вы просто и нам и себе геморрой создали. Нам по переделке кучи плагинов, вам по их проверке.

      А еще юзерам страдание и сожаление о том, что поверили вам и обновились до семерки потому, что оперативно все это сделать не получится.
      

      • +2

        Syrnik.com 21 мая 2016 05:09 #

        Исправят. Там getSettingsConfig() надо public сделать и его вызывать. Или новый метод, а тоесли кто-то перегружал этот getSettingsConfig(), то проблемы вылезут.

        Можно также еще и settings.php напрямую считывать.

        И это не Shop-Script. Та же проблема будет и у тех, кто на 6-й версии, но с обновленным фреймворком.

        Странно, я твои принтформы, кажется, уже на preview-версии 1.5.7 фреймворка запускал и там загрузка работала. Или я просто не помню уже...

        • +1

          ITFrogs 21 мая 2016 09:11 #

          Надеюсь. Пока что даже наличие бага не признали.
          
• +1

  km 21 мая 2016 04:39 #

  прикоооооольно, можно просто сделать Settings.html без указания в plugin.php

  *это я плагин watermark посмотрел
  

• +1

  ITFrogs 2 июня 2016 20:49 #

  Ура, я своего добился! :)

  1.5.10.39 Установленная версия: 1.5.9.32

  — Исправлена загрузка файлов на страницах настройки плагинов (вызывало проблемы с плагином Водяной Знак).