Показать меню раздела

Инкубатор идей

Здесь находятся Cырые и Дохлые Идеи. Сырые ещё недостаточно хорошо продуманы, чтобы приступить к реализации. Дохлые когда-то были Сырыми, но мы не поняли этого во-время.

Отдельно описанные задачи:

Краткие идеи

phBlockquote.less

Дизайн(ы) для оформления цитат: 

    <blockquote>
    Красивая цитата привлекает внимание пользователей и неплохо разбивает повествование.
    <cite>мысль Finar</cite>
    </blockquote>

Ранее предлагалось использовать вот такой phBlockquote.less

/* ДАННЫЙ ФАЙЛ СОДЕРЖИТ СТИЛИ ДЛЯ РЕЦЕПТА PmWikiPh/Blockquote */ 

/* ПОВТОРЕНИЕ ПЕРЕМЕННЫХ из variables.less (зачем? см. PmWikiPh/PmWikiPh )
   Если эти переменные не определены ранее и файл не компилируется, раскомментируйте.

  @gray-base:              #000;
  // @gray-darker:            lighten(@gray-base, 13.5%); // #222
  // @gray-dark:              lighten(@gray-base, 20%);   // #333
  // @gray:                   lighten(@gray-base, 33.5%); // #555
  @gray-light:             lighten(@gray-base, 46.7%); // #777
  @gray-lighter:           lighten(@gray-base, 93.5%); // #eee

  @border-radius-base:        4px;
  */

   blockquote { 
      min-height: 20px;
      padding: 19px;
      border: 1px solid @gray-lighter;
      border-left: 10px solid @gray-lighter;
      margin: 10px 0 10px 50px;
      border-radius: @border-radius-base;
      box-shadow: 0 1px 5px rgba(0,0,0,.5);

      &:before {
      display: block;
      float: left;
      height: 0px;
      content: "«";
      margin-left: -90px;
      line-height: 0;
      font-size: 600%;
      font-style: italic;
      text-shadow: 0px 0px 3px rgba(32, 32, 32, 0.3);
      color: @gray-lighter;
      }

      cite {
        display: block;
        color: @gray-light;
        margin-top: 20px;
        text-align: right;
        }
   }
Sep-2020: это нужно оформить отдельным рецептом, вместе с рекомендациями по предполагаемой wiki-разметке. Иначе нет смысла. Wiki-разметку можно взять отсюда:
May-2021: разметку, конечно, хорошо бы добавить, но почему бы по-умолчанию просто не использовать стандартный бутстрап?

SitemapsPack

Рецепт предлагал несколько вариантов генерации Карт Сайта для режима редактирования. Суть в том, чтобы представить карту сайта максимально компактно и масштабируемо, чтобы можно было вставлять ссылки на статьи в режиме редактирования.

Выглядело это так:

Рецепт был удален 2021-05-24 и из ядра, и вообще. Причина — верстка была в виде смеси HTML + вики, а CSS в виде LESS. Парадигма изменилась, проще переделать с нуля.

Всё это было придумано не только именно для Карт Сайта, а, например, чтобы при редактировании статьи выводить связанные с данной статьей материалы. Это удобно при создании хорошо-перелинкованных материалов в рамках одной темы.

Например:

  • несложно будет запрогаммировать листинг текущей Группы, чтобы прямо из режима редактирования статьи ссылаться на соседние
  • или вывести список статей, которые ссылаются на текущую
  • или вывести список статей, которые написал текущий автор
  • или вывести список статей из другой группы, $BaseName которых совпадает с данным
  • и т.д., и т.п…

iframe

Лучше всего было бы встроить ph-speedups.less в ThisSite/Syntax-Skin через iframe. Но iframe почему-то не поддерживаются!
Что с этим можно сделать?

  1. создать необходимую PHP-переменную или PV с кодом нужного iframe в editMode.php
  2. создать нормальный синтаксис iframe вида (:iframe %URL% :). Либо простенько с нуля, либо полнофункционально на базе вот этого рецепта: https://www.pmwiki.org/wiki/Cookbook/IncludeSite
  3. использовать phBruteFileLister.php , в котором читать нужный нам файл. В таком случае можно еще и подсветку синтаксиса сделать.
    • если это делать, то через ajax… как-то костыльно. С другой стороны, можно расширить концепцию и сделать возможность полноценно редактировать LESS/CSS код сайта прямо с него же с подсветкой синтаксиса.

.hidden-for-users ИЛИ класс .admin

Сделать такой класс, .hidden-for-users - "скрывает элемент от неавторизованных пользователей".

Либо более комлексный подход. Например: 

.hide-for-readers
.hide-for-editors
.hide-for-admin

.show-for-readers
.show-for-editors
.show-for-admin

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

Если делать класс .admin, следует учесть вот ещё что: 

 >>admin<<
 >><<

будет генерить 

 <div>
 </div>

поэтому, если внутри будет какой-то программинг, при определенных обстоятельствах выдающий NULL, &:empty {display: none;} не сработает, а хотелось бы! Чтобы это обойти, можно не делать класс, а вместо этого расширить синтаксис вот такой командой : 

 @admin@
 код-код
 @@

Создание пользовательского JS или CSS-кода для страницы

Старое и кривое решение (deprecated)

  • добавьте в конфигурационный массив рецепта FieldProcessing (создание полей) следующий элемент: 'CustomHeadCode' => 'textarea'
  • добавьте в EditForm input e_CustomHeadCode рядом с существующими элементами форм. Можете пометить его как-то, что, мол, поле только для программистов
    • обратите внимание, двойные кавычки не поддерживаются! Не знаю, как решить эту проблему, нам пока не бывало это нужно
  • во все макеты дизайна, которые вы используете, перед закрывающим тегом </head> вставьте код <!--markup:(:html:){$CustomHeadCode}(:htmlend:)-->
  • все, должно заработать!

Скорее всего, следует сделать немножко не так: в FieldProcessing (создание полей) добавить функцию, аргументом которой является ИмяПоля. Функция просто возвращает значение поля (заменив в нём спецсимволы). Таким образом, с помощью <!--function:FunctionName ИмяПоля--> можно будет неоднократно в любом месте tmpl-макета возвращать значение любого поля… Расширяя, лучше бы ещё дописать callback-вызов, чтобы, если таковая существует, вместо простого возврата значения вызывалась ещё одна функция ИмяПоля_processing(ИмяПоля). Таким образом, можно было бы делать собственные обработчики информации, хранящейся в полях.