MIXOH

Тему можно закрывать! Или удалять Разобрался сам.

Эмм.....ни у кого никаких мыслей? Или я затронул запретную для обсуждений тему? Тогда возможно в ЛС можно намекнуть Возможно я не совсем точно трактую мысль о "запрете" включения в плагин исходного текста родительской функции?

С чего вы взяли что я отождествляю какой-то конкретный метод с адресной строкой, где я такое написал? Я говорю о том, что зачастую, обмен данными с API предоставляющими более широкий или возможно, более защищенный функционал как правило организованы при помощи удаленного скрипта (-ов), Неважно каким методом. Просто потому что в скрипте удобней обрабатывать различного рода Encoded-данные, массивы и т.д. Адресная строка (как средство передачи того или иного запроса), затрагивается мной только потому, что автор вопроса пытается таким образом взаимодействовать с обсуждаемым здесь REST API. При этом пытаясь утверждать как раз обратное, по-типу "раз API продаваемых файлов так работает, значит и REST API тоже, ведь цель у них одна и та-же".

Обращаюсь к сообществу, за небольшой помощью в написании плагина. Идеи есть, но реализация применительно конкретно к IPS пока "хромает", а отсутствие каких либо мануалов еще более усугабляют правильное понимание. Суть в следующем, например, есть некая функция в одном из классов IPS, необходимо написать плагин, который бы в определенных местах заменял одну из строк этой функции, и добавлял бы еще пару строк. Как это правильно "оформить"? Интересует пример подобного рода манипуляций с кодом функции между вызовом этой самой "родительской" функции, и return-ом. Просмотрел множество плагинов, но большая часть из них является визуальными хуками, остальные же скорее переопределяют параметры функции, чем изменяют ее код. Заранее благодарен за информацию. Если что, с меня готовый плагин

Согласен, но во-первых не все из методов удобны для применения прямо вот так вот в адресной строке, во-вторых, я же написал, "большинство API". Понятное дело конечно даже простенький скрипт, возвращающий в ответ на запрос, строчку "Hello world!" тоже в какой-то степени можно считать API, тем не менее, когда речь заходит о предоставлении более-менее широкого интерфейса взаимодействия, никто конечно всерьез не рассчитывает на то что все это будет происходить прямо в адресной строке, не так ли. Не говоря уже о том, что определенное множество из этого "большинства" API в принципе изначально базируется на аутентификации в той или иной степени. ИМХО мы прекрасно понимаем смысл беседы, но этими уточнениями уходим от темы

ОЙ! Удалите лишнее, то ли у меня то ли на мафии заглючило

ИМХО сколь-нибудь достойного, а тем более полного, нет. По крайней мере в паблике не встречал. Поэтому просто начал переводить сам, но ввиду отсутствия очень уж острой необходимости, плюс некоторой муторности этого мероприятия (все таки перевод не машинный), движется это дело крайне медленно. ОДаже когда время от времени я возвращаюсь к этому вопросу, очень много времени уходит на тестирование "правильности" строк в конкретном контексте, добавим сюда еще и сложности движка по плюрализации......вобщем вот такая ситуация. ИМХО сколь-нибудь достойного, а тем более полного, нет. По крайней мере в паблике не встречал. Поэтому просто начал переводить сам, но ввиду отсутствия очень уж острой необходимости, плюс некоторой муторности этого мероприятия (все таки перевод не машинный), движется это дело крайне медленно. ОДаже когда время от времени я возвращаюсь к этому вопросу, очень много времени уходит на тестирование "правильности" строк в конкретном контексте, добавим сюда еще и сложности движка по плюрализации......вобщем вот такая ситуация.

ИМХО сколь-нибудь достойного, а тем более полного, нет. По крайней мере в паблике не встречал. Поэтому просто начал переводить сам, но ввиду отсутствия очень уж острой необходимости, плюс некоторой муторности этого мероприятия (все таки перевод не машинный), движется это дело крайне медленно. ОДаже когда время от времени я возвращаюсь к этому вопросу, очень много времени уходит на тестирование "правильности" строк в конкретном контексте, добавим сюда еще и сложности движка по плюрализации......вобщем вот такая ситуация.

С чего-бы......просто разжевали вы совсем не то о чем шла речь как в этой теме, так и в вашем первом вопросе. Тогда тем более непонятен ваш вопрос, о том, как способом взаимодействия с одним API пытаться общаться совершенно с другим API. Пожалуй это все что у них общего, не находите? А еще они оба относятся к IPS и т.д., но в корне, принцип взаимодействия с движком совершенно разный. Так Вам изначально на ваш вопрос также прямо указали, что Для REST API не подходит Я привел вам в одной из предыдущих цитат, полный код запроса helo. Вставьте в пхп файлик, и будет вам и сформированный запрос и ответ на него от API.

Собственно, цитата из первого поста, как нельзя лучше характеризует отличия Именно по такому принципу и работает API для продаваемых файлов. Я имею ввиду его работу через require_once '../../../../init.php

Вы просто говорите совершенно не о том. (насколько я вижу, вопрос из первого вашего поста, и попытка нам "тупым" разжевать, то о чем вы спрашивали из последнего поста, ничего общего между собой не имеют (ну кроме слова API пожалуй) Меньше пафоса! Начнем с того, что API продаваемых файлов (точнее лицензий), это во-первых давнишняя штука, появившаяся задолго до REST API, во-вторых ей для работы совершенно не нужен API ключ, относящийся к REST API. Функционал у этого API слишком узок, для необходимости использования ключей, и отсутствия необходимости в HTTP авторизации. ИМХО в будущем его могут полностью убрать, переложив на плечи "новог" API. То есть, вкратце, разница между этими двумя механизмами, фактически в функционале и предоставляемых возможностях. Если "старый" API-лицензий, работает исключительно с этими самыми лицензиями, то "новый" API предоставляет доступ практически ко всем функциям движка. Вам это все сохранить в PHP файл (заменив URL и ключ на ваши), залить на хост и запустить этот файлик?

Вы какой-то свой особый "велосипед" пытаетесь изобрести? Я не совсем понимаю, зачем вам строка с GET запросом, вы с API собираетесь работать забивая ручками запросы в адресной строке? Мне кажется API совсем не для этого. Да и потом одно дело запросить таким макаром HELO, и совсем другое - что-нибудь посерьезней. JSON в ответах вы тоже ручками будете разбирать? Зачем мысли и догадки, в референсе по REST API все достаточно ясно написано. <?php $communityUrl = 'http://www.МОЙ_ФОРУМ.ru/'; $apiKey = 'bae56487dd06e3e8530243bfd793bd66'; $curl = curl_init( $communityUrl . 'api/core/hello' ); curl_setopt_array( $curl, array( CURLOPT_RETURNTRANSFER => TRUE, CURLOPT_HTTPAUTH => CURLAUTH_BASIC, CURLOPT_USERPWD => "{$apiKey}:" ) ); $response = curl_exec( $curl ); echo $response; Соответственно $response вернет вам правильный ответ от REST API Большинство API (в том числе и IPS4 REST API) предназначены для взаимодействия с удаленными скриптами, а не с адресной строкой, если что.

Прошу прощения, предыдущий вариант без гостевой группы. Вот правильный, и с расширенным окошком. Sticky Message_750px.xml

Ну вот например как вариант изначально максимальная ширина вместо 250 изменена на 750. А вообще это дело индивидуальное, поэтому если хотите в последствии можете сами подправить в stickyMessage.css Sticky Message_750px.xml

О чем именно речь? Ага.....поюзал немного, и я так думаю понял о ширине чего речь. Гляну завтра. Вообще судя по всему плагин писан чисто так....на коленке, поэтому особо от него требовать чего-то не стоит. Но если его немного "причесать", то вполне годная вещь, для своего узкого применения

Сейчас гляну, я его не ставил и не проверял. Только что проверил, все сохраняется, и применяется к конкретным группам не распространяясь на другие.

Не знаю логики автора, но ИМХО этот плагин пожалуй только для Гостей и полезен, ибо для остальных хватает и других способов уведомлений. Какой смысл был в ограничении селекта?

Поправить код Вот вариант с возможностью выбора Гостевой группы Sticky Message.xml

По большому счету tar это не архив, в том смысле что он не сжатый. Под Win прекрасно делается архиватором 7zip

D-rA, Благодарю! Будьте любезны, еще вот это: https://community.invisionpower.com/files/file/7449-auto-welcome/

Это понятно, но ради исключения влияния хостинга, попробовать работу чистой установки думаю все-же стоило бы Потому что содержимое папки Datastore и чистка кеша в АЦ это немного разные вещи. В этом и нужно искать причину (в кеше и иже с ним)

Вы ошибаетесь Хотя-бы для того чтобы локализовать причину (движок или хостинг), не вижу сложностей Иначе гадать на кофейной гуще придется еще дольше

Ну вроде ничего криминального..... Тогда скорее всего остается только вариант с кешем, возможно из-за изменения memcashe возможно еще по каким-то причинам. процитирую напоследок свои рекомендации, дальше думаю ничем более не помогу

Если речь действительно о рекомендациях, тогда скорее всего cURL таки установлен, но меньшей версии, тогда и это не принципиально. Тогда еще открытым остается вопрос с модулями PHP Datastore чистили? Может имеет смысл (хотябы для проверки), попробовать заинсталлить движок с нуля, проверить, затем возможно даже подкинуть бекап базы, еще раз проверить?

Ну по версиям ПХП вопросов быть не должно, хотя опять-же, нужно убедиться что необходимые модули стоят. По скулю тоже не столь принципиально. Вместо memcaсhe я так понимаю в АЦ было перед переносом включено "Без кеширования". А вот отсутствие cURL думаю это серьезная проблема. Это вы скриптом проверяли, или навскидку?