CityCat4, с одной стороны вы как бы правы, с другой, вы же понимаете, что это чисто политическое решение. Да и зачем жаловаться, если у вас в итоге ничего не перестало работать?
Правда, это не объясняет, почему сбой произошёл на ZIP архиве малого размера (который даже после распаковки 2 мегабайта никак не превысит)... Я потестирую ещё, отпишусь, что будет.
acwartz, совершенно верно. Но я же не единственный автор расширения, загружающего аудиотреки. Вот мне и интересно, как выкрутились остальные разработчики
acwartz, я же не из вредности или принципа это всё затеял. Я действительно не понимаю, как его можно/нужно переписать.
Этот код изначально не предназначен для того, чтобы его понимали. Учитывая его назначение
Что до безопасности - не знаю, совершенно же очевидно по тому, в каком контексте он вызывается, что он просто даёт URL для последующей отправки в Downloads API, там видно, что сервер вконтактовский, и видно, что расширение файла всегда mp3. Но они продолжают убеждать меня/самих себя, что это замаскированный вирус. Ну смешно же
А что скажете насчёт Full HD 24", точка крупновата? Я на таком программирую правда, а не рисую, но я близорукий и вижу пиксели что с очками, что без них (с очками особенно сильно). А хотелось бы их не видеть в идеале, как на телефонах.
Что мне взять тогда, если 21.5 Full HD для меня слишком мелко (увеличение масштаба сокращает количество полезного контента)? Может, 1440p 24"?
Ankozar, вы, мне кажется, не понимаете принцип работы json_encode. Ей на вход нужно передавать не строку, а именно массив или объект (строку в формате JSON она как раз вернёт).
Мне кажется, вам просто нужно сделать правильное экранирование символов перед отдачей в json_encode, хотя вообще говоря она должна автоматически всё что надо экранировать. Можете скинуть куда-нибудь фрагмент JSON, который у вас не парсится? Я посмотрю, на что именно он ругается.
Насколько я помню, я тогда выкрутился созданием временного файла средствами PHP на своём сервере перед отправкой его в вк.
Кроме того, уже сейчас, оглядываясь назад, я полагаю, что можно было решить проблему, установив у XHR объекта HTTP-заголовок с правильным Content-Type (например, "application/octet-stream").
Юрий, это не очень удобно сделано на самом деле. Я понимаю, что борьба со спамом и все дела, но есть кейсы, когда это нужно. Пример: делаю микро-сервис постинга по расписанию под заказ. Токен сообщества не годится, потому что у заказчика много сообществ, а токен, полученный для сайта через Authorization Flow, постить ничего не может. В итоге приходится получать токен вручную копированием. Не очень большая проблема конечно, но при каждом слёте токена придётся его снова в базу/код ручками вносить, это тяжко. И слава богу, что этот токен не имеет привязки к IP, иначе был бы вообще трындец (получаем токен из браузера, а постить контент должен сервер).
Максим Федоров, не совсем вас понял. В репозитории мои методы обычно используют запросы DQL, и там всё уже возвращается "не лениво", то есть всё приджойнено. Я именно пытался работать через методы самих Entity, и при этом пытался использовать array_walk/array_map вместо циклов, отсюда и получал ошибку. Подтягивание вложенных структур происходит каким-то образом автоматически в момент обращения по индексу массиву, либо по вызову count().
Вопрос был - можно ли указать какой-то флаг для Doctrine, чтобы она на время работы скрипта (или для конкретного метода в целом) отключила ленивое получение данных из БД.
strelok011, прочитал статью, понял, что сложность в том, что мобильный браузер должен нормально отображать "десктопные" сайты, не адаптированные под мобайл, и уметь их произвольно масштабировать.
Но я всё же не вижу большой проблемы: браузер мог бы попытаться отрендерить страницу в ширине, определяемой размером экрана (как при указанном мета-теге), и если она не поместилась в ширину, то есть требуется скролл - отображать её по правилам десктопа, то есть разрешить масштабирование, подобрать наиболее удачный начальный масштаб исходя из размера шрифта на странице и той ширины, на которой скроллинг больше не требуется, и так далее. А если же метатег указан - он мог бы переопределить эти автоматически найденные значения на те, которые нужны разработчику.
Если же скроллинг не нужен даже на относительно малой ширине экрана девайса (в виртуальных пикселях) - то и выводить сайт можно сразу в масштабе один к одному с запретом масштабирования (а если масштабирование всё-таки нужно, то уже задача вебмастера указать это). Так как скорее всего, если скроллинг не нужен, и страница помещается во вьюпорт - она либо полностью свёрстана под текущую ширину (адаптив или мобильный поддомен), либо это служебная страница, где есть только белый фон и 2-3 слова в одном абзаце на нём - в настоящее время такие страницы выводятся крайне мелко и почти не читаемо, пока не увеличишь масштаб, как минимум на моём телефоне 2011-ого года, что как по мне довольно глупое решение.
Что я имею в виду под "умещается"? Ну вот есть у нас страница с кучей абзацев (и например списками между ними). При этом ни у одного элемента не указано свойство width со значением больше нашего вьюпорта (либо указано меньшее, либо стоит в auto). В этом случае контент помещается (на самом деле, не обязательно, потому что есть ещё минимальная требуемая ширина, для абзаца это длина самого длинного слова, для пункта списка - то же самое плюс маркер и отступы, для таблиц - там свой алгоритм, в общем тоже нельзя сжимать бесконечно). В общем, если браузер видит, что всё поместилось (обычно когда нет, у нас появляется возможность скроллинга вправо и белая полоса по правой границе) - можно отображать всё так, как будто этот метатег указан, даже если его случайно забыли. Не вижу причин делать иначе, ведь десктопный сайт заведомо не поместится во вьюпорт из-за кучи элементов, имеющих явно заданный больший размер по ширине, и для них всё будет работать так же, как работает сейчас, то есть ничего не поломается.
strelok011, а, понятно. Ну про виртуальные пиксели я знал конечно же. Но вот не знал, что оно из коробки так не работает. Хотя казалось бы, должно - ведь мобильный браузер прекрасно знает dpi дисплея устройства (в Андроиде можно вроде какой-то метод дёрнуть, чтобы получить dpi системы из конфигов). Непонятно, зачем заставлять вебмастеров писать эту лишнюю строчку, когда можно было бы делать это автоматически.
Добавил, и правда проблема решилась, большое спасибо.
strelok011, спасибо. Про второе я как раз был в курсе. А вот первое не подскажете для чего и что оно делает? Я видел эту конструкцию, ног не понимаю её назначения.
Но всё равно мне интересно - что за псевдоредирект такой хитрый, и только в хроме?