Marat_Kh

Всё, более менее современное сейчас активно юзает наследование

Например так:

class galery extends base_action {  

/* 

  url: /galery/page/(int) $page

  url: /galery/image/(int) $id

*/

  private $template = 'gal.tpl', $db=null;



  private function read($table, $where, $fields, $limit='LIMIT 0, 10'){

    return DB::q('SELECT', $table, $fields, $where, $limit )->by_Array();

  }

  

  public function page(){

    $page= isset(Request::URL_Section[2]) ? (int) Request::URL_Section[2] : 0;

    $start = $page * 10;

    echo $this->out($this->read('galery', ['is_visible'=>1], ['id','thumb','alt'], "LIMIT {$start}, 10"));

  }



  public function image(){

     echo $this->out($this->read('galery', ['is_visible'=>1, 'id'=>(int) Request::URL_Section[2]], ['path','thumb','title','alt'], 'LIMIT 1'));

  }



  private function out ($data){

    $twig = ....;

    $template = $twig->loadTemplate($this->template);

    return $template->render($data);

  }

}



class supergalery extends galery {

/* 

  url: /supergalery/page/(int) $page

  url: /supergalery/prosmotr_kartinki/(int) $id

*/

  

  function prosmotr_kartinki(){

    $this->template='super_galery_simpe.tpl';

    echo $this->out(

      array_merge(

          $this->read('supergalery', ['is_visible'=>1, 'id'=>(int) Request::URL_Section[2]], ['path','thumb','title','alt','reviews'], 'LIMIT 1'),

          $this->read('supergalery_comments', ['is_visible'=>1, 'id'=>(int) Request::URL_Section[2]], ['user_id','comment','user_name'], 'LIMIT 30')

      )

    );

    DB::q('UPDATE', 'supergalery', ['reviews'=>'`reviews` + 1'], ['id'=>(int) Request::URL_Section[2]]], null );

  }



}

набросал за 5 мин для иллюстрации как делают. Особенно самописатели😂 Если модули в этом стиле прибавить к автолоадеру, классу Request (для обработки и SANITIZE REQUEST_URI, пост, гет и прочих кук), роутеру и добавить класс-надстройку, например над PDO, для манипуляций с БД, то вот он, простейший, но вполне функциональный и быстрый фреймворк:p

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

Увидев строку в двойных кавычках рнр пытается найти в ней переменные и заменить их соотвт. значением + обрабатывает управляющие последовательности. Следовательно, определив таким образом строку, заставляем рнр сделать лишнее действие. Отсюда вывод 1: если строка не "собирается" путем включения в нее переменных, лучше в одинарных кавычках. Справедливости ради, разница во времени выполнения если и есть, то микроскопическая.

А если, для того чтобы получить строку надо включить в нее переменные, то из вариантов

$s = 'Hi ' . $user . '!'; //или лучше $s = 'Hi '; $s.=$user; $s.='!';

$s = "Hi {$user}!";

с увеличением длины строки лучше конкатенация. Иными словами, если строка небольшая, то без разницы, а если увесистая, то конкатенация в варианте "или лучше". Когда то ставил эксперимент, на строке символов так с 60-80 разница появляется.

$f='http://open.api.ebay.com/shopping?'

 . 'callname=GetSingleItem&'

 . 'responseencoding=JSON&'

 . 'appid=' . $apiId . '&'

 . 'siteid=0&'

 . 'version=967&'

 . 'IncludeSelector=Variations,Details,ItemSpecifics&'

 . 'ItemID=311777874402';



 print_r(json_decode(file_get_contents($f)));

Доки, можно поиграть IncludeSelector , список допустимых значений по ссылке

Черный ход попросили открыть.😂

Например это:

assert('file_put_contents("33.php","<?php echo \'Hi\';?>")');

создаст файл 33.php , который выведет Hi на экран, но в $_REQUEST[R01] вероятно что то другое сунут.

Вот тут может

 

<findItemsAdvancedRequest xmlns="http://www.ebay.com/marketplace/search/v1/services">

  <itemFilter>

    <name>Seller</name>

    <value>Имя продавца</value>

  </itemFilter>

  <paginationInput>

    <entriesPerPage>100</entriesPerPage>

  </paginationInput>

  <outputSelector>.....</outputSelector>

</findItemsAdvancedRequest>

Число для выборки диапазона Select product_id .... WHERE ves BETWEEN 2 AND 5; Можно и в 1, раньше так и было (Ид товара | Ид параметра | Строка | Число) , потом решил разнести. Быстрее выборка получается.

В форме фильтра будут показаны те параметры где не 0, соответств. образом отсортированы

В листинге категории будут показаны только те характеристики, что отмечены галочками. Для каждой модели будут указан диапазон (у 1 модели могут быть модификации), если это число, или перечисление если строка:

- Максимальный вылет манипулятора,м : 8.00-19.00

- Двигатель : Cummins, КАМАЗ

Разные варианты пробовал, но в итоге чаще применяю такое:

1. На этапе загрузки/обновления определяется набор параметров к каждой категории, одновременно формируется таблица для показа в карточке "наименование параметра | значение" (3-й тип по вашей классификации).

2. Разные товары с одинаковым ИД склеиваются с определением разницы в параметрах => 1-тип характеристик.

3. Характеристики в 2 таблицы Ид товара|Ид параметра|значение (attr_num / attr_str ) в зависимости от данных, если все значения числа, то в таблицу attr_num, иначе в attr_str. От этого же зависит поле "тип параметра" в таблице наименований параметров.

4. В админке механизм выбора параметров для отображения в форме "фильтра" ("Сортировка для конфигуратора") и списка параметров для вывода в листинге ("В таблице комплектации"). Во вложении скрин одного из древних вариантов, но принцип тот же.

Можно и CNAME. Точка после *.site.com или просто *

Если для поддомена(ов) нет информации DNS, которую можно получить, например, dns_get_record , то никак. Запрос до Вашего Апача не дойдет :(

Не, смотрите например сюда