Александр Зеленин, "Чистый" WP ничего кроме блога не умеет. Что бы создать то, что "хочется" нужно быть хотя бы поверхностно разбираться в (как бы это назвать правильно...) сайтостроении. Да и админка несколько запутана для неподготовленного человека который первый раз решил попробовать сделать сайт и впервые открыл админку.
Согласен, что настолько чистым фон сделать вряд ли получится, однако в несколько слоев наложенные друг на друга радиальные градиенты вполне могут решить проблему, просто это из серии как делать не нужно, но на конкретно поставленный вопрос будет скорее да чем нет.
У Вас на сервере есть php интерпретатор.
Если не вдаваться в подробности, интерпретатор получает на вход файл php и выполняет его.
При обращении к серверу он просто по запросу "смотрит" к какому файлу Вы обратились и передает интерпретатору php путь к файлу который нужно выполнить, интерпретатор в свою очередь возвращает response (ответ) серверу и тот добавляя к ответу заголовки отправляет ответ клиенту в браузер.
Такое долгое вступление было для того что бы Вы поняли, что на сервере есть интерпретатор который может принимать только php файлы и только их! Т.е Jade шаблон интерпретатор обработать не сможет.
от сюда вытекает, что сначала Jade нужно скомпилировать в понятный для интерпретатора формат - этот процесс и называется компиляцией.
Думаю теперь когда мы разобрали с терминологией перейдем дальше:
У нас есть Jade. Внутри которого можно прописать php код который будет обрабатываться интерпретатором, интерпретатор выполнит только то что будет внутри <?php ... ?> или <?= ... ?>, все что за этими тегами будет просто выброшено в поток вывода.
Но ведь нам не нужно что бы в response (Ответ), в браузер, ушел не скомпилированный Jade и нам нужно его перехватить и записать в переменную.
Поэтому, мы сначала включаем буферизацию, с помощью функции ob_start(), а после в нужный момент функцией ob_get_contents() получаем все содержимое (после включения буферизации) из потока вывода в результат функции и записываем в переменную (в моем ответе это переменная $jadeContent), разумеется, в этом содержимом, вместе c jade, будет уже выполненный интерпретатором php код. После этого полученный результат, который в переменной будет уже без тегов <?php ?> т.е там где было:
"
body
<?php
if (1 == 1) {
print 'Равно 1';
}
else {
print 'Не равно 1';
{
?>
"
Станет:
"
body
Равно 1
"
Т.е весь php уже выполнился и мы получили чистый Jade который можно передать в Jade компилятор.
Наверняка Вы имели ввиду:
canvas.drawImage() и после canvas.toDataUrl().
Впрочем, думаю если покопаться, то что-то можно из этого на шаманить.
Спасибо за наводку.
Возможно, но согласитесь - это уже костыль. Раз уж мы уговариваем пользователя что-то установить. Почему бы не написать полноценное приложение которые бы сохраняло картинки в ФС клиентского компьютера "по человечески" и без "костылей" и не попросить его установить написанное приложение?
Stalker_RED: Не буду утверждать, т.к не задавался вопросом, однако, сможете ли Вы после этого получить blob этой картинки которая получена таким образом? Ведь задача стоит не отрендерить картинку на странице.
Если это возможно, не могли бы Вы привести пример, мне бы это так же пригодилось бы, как раз в скором времени может очень пригодится, если таким способом это возможно, то разумеется я солидарен, так гораздо удобнее.
Через XMLHttpRequest не получится если сервер не передаст заголовок
Origin: example.com
где, example.com - это домен с которого делается запрос на получение картинки и как Вы понимаете такой заголовок владелец, сайта жертвы устанавливать не будет.
Думаю, что развивать тему в сторону, социальной инженерии так же не стоит и переводить разговор в русло "как убедить владельца сайта установить заголовок xxxx: yyyyy;"
Ах, да. Забыл.
Для непосредственно сохранения единственное, что вижу - это копать в сторону localStorage, но при этом вкладка будет жрать кучу оперативной при этом, после пары тройки фото - не забывайте. Почитайте еще по File API, возможно после получения нужных привилегий будет возможность сохранять картинки прямо в Файловую систему на клиенте. Других вариантов скорее всего нет.
Раскрутить через Яндекс Директ, свой стартап использующий ресурсы Яндекса, через Яндекс Api, для привлечения аудитории Яндекса с платформы Яндекс Фотки.
Голова кругом. ))
А вот я с Вами в корне не согласен.
Если сервис станет популярным и соберет свою аудиторию, то это будем отличным поводом к замещению Яндексовского начала (бекэнда) на свое и так вплоть до полной независимости платформы.
Другой вопрос есть ли в этом смысл? Если Яндекс не продолжает настолько интенсивно развивать эту платформу у себя, хоть возможности у них для этого есть, значит для этого есть основания и скорее всего они плачевные для данного стартапа и выливаются они в отсутствие интереса со стороны аудитории к Я.Фото.
А для привлечения аудитории к своему сервису, нужно как минимум найти аудиторию которая постоянно, не только хостит свои фотки на Яндекс, но и активно их использует в сети, а такая аудитория очень маленькая, большинство отдали свой выбор в пользу более узконаправленных и специализирующихся на этом сервисах.
Я подвожу к тому, что Яндекс фотографиями пользуются те кого устраивает Яндекс, если бы этой аудитории нужны были бы несколько другие условия / функции / интерфейс (которые может предложить данный сервис) они бы уже давно воспользовались бы услугами других фотохостингов.
Так, что сказанная Вами участь, маловероятна. При невероятной удаче, набрав определенную репутацию и опыт сервис мог бы сохранить аудиторию подменив бэк и получить независимость от Яндекса. Но и даже это маловероятно. Мысль крутить дальше, пока ничего что бы меня заставило бы заинтересоваться я не вижу.
Мне кажется Вы, возможно, создаете для себя дополнительные проблемы!?
Если я правильно понял, то Вы Создаете Jade шаблон, компилируете в html который после скармливаете в smarty?
Не буду брать на себя ответственность осуждать такой подход - причины могут быть разными, но это как минимум странно.
Больше всего я люблю vanilla php шаблоны, т.е их полное отсутствие в некотором смысле. Считаю, что php не нуждается в шаблонизаторах т.к сам по себя является отличным представителем оной категории.
Поэтому для меня задача выглядит след. образов.
На php (который сам по себе является отличным шаблонизатором) написан компилятор другого шаблонизатора (Jade), компилируемый в vanilla php (так же расматриваем как шаблон), который в свою очередь уходит в третий шаблонизатор (он же smarty), который в конечном счете все это выхлопнит все в тот же vanilla php который в конечном счете и выполнится интерпретатором.
В принципе то мне понятен профит от использования Jade (c более лаконичным и коротким синтаксисом), но зачем smarty раз уж Вы пишите на Jade, зачем это звено? Без шаблонизатора посредника ведь Вы добиваетесь того что Вам нужно, а смысла от этого звена я не вижу?
Если это все же необходимая архитектура, то будем дальше искать решении. Только опишите подробнее как Вы это все замудрили и как будет использоваться.
Если Вы мне предоставите исходный материал. Т.е изображения с которыми нужно работать - я попробую.
Если не понравится сильно не пинайте т.к это не является моей прямой специальностью, скорее как хобби (хобби фотография, но как Вы понимаете приходится частенько и Photoshop открывать).
Если же понравится, можете отблагодарить на пару дошираков как говорится :) но и это в прочем не обязательно.
В общем, если нужна моя помощь- напишите на nick.molodoy@gmail.com.
Простите, случайно отправил!
Но думаю, что Вы поняли, то что я описал и допилите под себя.
Сам смысл заключается в том, что бы пропустить через интерпретатор php сам шаблон, выполнить все инструкции и php код и в конечном счете получить чистый Jade шаблон который можно скормить jade компилятору.
Подумайте, насколько допустимо было бы использовать комбинирование?
Разумеется что для каждого отдельного поля таблицы создавать отдельные коллекции не разумно, например, создавать в mongo коллекцию `links`, для хранения ссылок указанных в профилях.
С другой же стороны хранить профили пользователей в mongo, отдельно от непосредственно аккаунта, хранящегося в том же MySQL, кажется более разумным.
Это гораздо удобнее в использовании и более правильно с точки зрения реализации, нежели хранение не сериализованных данных в бд, не поддерживающей такую возможность (иногда у Вас просто не будет возможности десериализовать данные, поскольку, например MySQL не уведомляя Вас просто обрежет сериализованную строку до размера установленного максимальным, на конкретно данное поле таблицы и как Вы понимаете получить массив в целости не получится обратно).
Однако описанный подход так же не без изъяна, получая более комфортную работу с данными конкретной записи, ввиду хранения самих данных в разных источниках у нас усложнится процесс формирования списков из нескольких записей.
Т.е если мы просто получим несколько записей из MySQL а после, в каждой итерации цикла будем подтягивать связанные данные записи из Mongo у Вас просядет производительность.
Придется ухищряться след. образом:
1. Формируем запрос на получение записей из MySQL.
2. Получаем записи из MySQL
3. Формируем список идентификаторов записей (если данные у нас сопоставляются по идентификатору),
4. Получаем все связанные документы из MongoDB одним запросом.
5. Объединяем данные из двух БД в один объект модели.
Немного, расширю свой ответ. Насколько я понимаю, Вы хотите отслеживать не размер непосредственно окна, а размер какого либо блока. Я правильно понимаю?
Если так то Вы можете отслеживать событие resize окна браузера точно так же как я описал. Только в обработчике, необходимо проверять не размер окна ( $(window).width() ), а размер необходимого блока.
После того как размер мы узнали нам необходимо определится с т.н breakpoint'ами - значения размеров окна, выходя за пределы которых мы должны производить какие-то манипуляции над элементами страницы и указать эти самые критерии в конструкции условия или нескольких условий по аналогии приведенного мною примера на jsfiddle (в нем breakpoint'ом является размер 620px).
Думаю, что по комментарию можно будет уловить принцип работы, но если потребуется более развернутый ответ я создам новую демо с более реальным применением и максимально его прокомментирую.
Простите, возможно я несколько не внимателен. Однако, касаемо моего вопроса данный каркас сохранил все теже самые ограничения. Не могли бы Вы несколько развернуть Ваш ответ. Спасибо.
