Jump to content

Sebi

Members
  • Posts

    78
  • Joined

  • Last visited

  • Days Won

    5

Sebi last won the day on March 7

Sebi had the most liked content!

About Sebi

  • Birthday March 8

Contact Methods

  • Website URL
    https://www.sebi.dev

Profile Information

  • Gender
    Male
  • Location
    Gütersloh, Germany

Recent Profile Visitors

1,628 profile views

Sebi's Achievements

Full Member

Full Member (4/6)

199

Reputation

  1. A quick update... Version 1.2.5 allows you to deactivate url hooks and fallback into the legacy ProcessPageView::pageNotFound behavior. That's now possible in the module config. I discovered, embarrassingly just after the release of the new version 1.2.4, a case where switching to the URL hook actually causes a breaking change. In all tests before this was not noticed, so sorry if anyone discovered something similar. Now, in any case, it is easy to switch back to the old hook. Now to the problem: Maybe someone reading this has some deeper insight and can help me to understand the issue. I have a page on which I have included @Wanze`s SeoMaestro field and wanted to read the values from it via Api: <?php $page = wire('pages')->get('/'); if ($page->template->hasField('seo')) { $seoString = @$page->seo->render(); } That actually works fine when it's done in an ProcessPageView::pageNotFound hook. But if I use a url hook and call it, the seo->render() call will throw the following error: { "error": "Method Page::localUrl does not exist or is not callable in this context", "devmessage": { "class": "ProcessWire\\WireException", "code": 0, "message": "Method Page::localUrl does not exist or is not callable in this context", "location": "\/processwire\/wire\/core\/Wire.php", "line": 564 } } I've managed to step through the code and find out the source of the exception. It's a call of page->localUrl in SeoMaestro's PageFieldValue class: https://github.com/wanze/SeoMaestro/blob/master/src/PageFieldValue.php#L158 Any ideas? 😐
  2. With AppApi's new version 1.2.4 we now use URL Path Hooks! The old ProcessPageView::pageNotFound hook still remains, but is only used as a fallback if the ProcessWire version does not support the url path hooks. Thanks to @kongondo and @adrian who kept pushing me in the direction of including url path hooks! I also revised the logging a little bit. In the access log (which can be activated via the module settings) the correct paths from the request are now entered. And an entry in the access log really only occurs if no error has occurred. Otherwise an entry is triggered in the appapi-exceptions log. You can download the new version now in the ProcessWire modules page, Github or via auto-update in your ProcessWire UI. Thanks for using AppApi! 🙏
  3. Hey @paulbrause, I managed to update my test-setup to ProcessWire 3.0.204 and PHP 8.1.1, but I cannot reproduce this error. Login via POST to /api/auth/ with a Basic Auth header still works fine. But of course I would still like to help you and fix a possible bug - maybe in a special edge case. Can you maybe downgrade your PHP version to 8.1.1 to rule out that it's not a bug regarding the PHP version? The error comes from a function call to the quote function of WireDatabasePDO. I do not call that function directly in AppApi, but it could be called from any other database function that I use. Can you please verify that the api-application that you created in ProcessWire's backend does not have any empty field? Are the secrets correctly set? Thank you for using AppApi and I hope that we can quickly find the cause of this error!
  4. Hey @toni! Sorry, I totally missed your mention 😬 I recently had to deal with multilanguage urls in an api and tried a lot of things. It's something that must be handled in your endpoints and it's a matter of taste. If it comes to frontend-urls, the first way should be preferred because language-specific urls (not with language as GET-param) seem to be preferred by Google, so its better in terms of SEO optimization. Have a look at the code of my additional module AppApiPage which adds an api/page endpoint. I've included handling for ProcessWire's multilanguage-urls and I've added setting the language via GET-param as a fallback. Hope that helps you out!
  5. @flydev 👊🏻 Yep, that's right. The module has basically the same code as the PageApiAccess class that I posted in the other thread. I added an improvement for handling the "lang"-GET-param, that enables you to switch to another language in a multilang environment. But everything else is the same code.
  6. I just released a new extension module AppApiPage (waits for approval), which handles the initial steps from my post above completely automatic. You install AppApi and AppApiPage. That makes the /api/page route available and you only have to add the code on top of your template php to add a custom JSON output to your pages. <?php // Check if AppApi is available: if (wire('modules')->isInstalled('AppApi')) { $module = $this->wire('modules')->get('AppApi'); // Check if page was called via AppApi if($module->isApiCall()){ // Output id & name of current page $output = [ 'id' => wire('page')->id, 'name' => wire('page')->name ]; // sendResponse will automatically convert $output to a JSON-string: AppApi::sendResponse(200, $output); } } // Here continue with your HTML-output logic... I hope that this makes it even simpler to add a full-blown JSON api to new and existing pages.
  7. AppApiPage adds the /page endpoint to the AppApi routes definition. Makes it possible to query pages via the api. This module relies on the base module AppApi, which must be installed before AppApiPage can do its work. Route Description /api/page/ Calls the root page of the page-tree /api/page/42 Will call the page with id=42 /api/page/my/test/page Calls your page with path my/test/page After installing AppApi and AppApiPage, you simply have to add the following code at the top of your ProcessWire-template to provide your page with a custom JSON output: <?php // Check if AppApi is available: if (wire('modules')->isInstalled('AppApi')) { $module = $this->wire('modules')->get('AppApi'); // Check if page was called via AppApi if($module->isApiCall()){ // Output id & name of current page $output = [ 'id' => wire('page')->id, 'name' => wire('page')->name ]; // sendResponse will automatically convert $output to a JSON-string: AppApi::sendResponse(200, $output); } } // Here continue with your HTML-output logic...
  8. Hello all! I guess I'm a little late to the party, but here's an explanation to my AppApi approach. I basically wanted to achieve exactly the same thing with my projects as well: A universal JSON api that I make all public ProcessWire pages also queryable as JSON. For this I use the combination of my Twack module and AppApi. Twack is a component system that allows me to get a JSON output from each ProcessWire page in addition to the standard HTML output. Twack registers a route that allows to query each Page from the PageTree (via ID or Path). But for this route you don't need the Twack module, of course. As here it would work only with the AppApi module: routes.php: <?php namespace ProcessWire; require_once wire('config')->paths->AppApi . 'vendor/autoload.php'; $routes = [ 'page' => [ ['OPTIONS', '{id:\d+}', ['GET', 'POST', 'UPDATE', 'DELETE']], ['OPTIONS', '{path:.+}', ['GET', 'POST', 'UPDATE', 'DELETE']], ['OPTIONS', '', ['GET', 'POST', 'UPDATE', 'DELETE']], ['GET', '{id:\d+}', PageApiAccess::class, 'pageIDRequest'], ['GET', '{path:.+}', PageApiAccess::class, 'pagePathRequest'], ['GET', '', PageApiAccess::class, 'dashboardRequest'], ['POST', '{id:\d+}', PageApiAccess::class, 'pageIDRequest'], ['POST', '{path:.+}', PageApiAccess::class, 'pagePathRequest'], ['POST', '', PageApiAccess::class, 'dashboardRequest'], ['UPDATE', '{id:\d+}', PageApiAccess::class, 'pageIDRequest'], ['UPDATE', '{path:.+}', PageApiAccess::class, 'pagePathRequest'], ['UPDATE', '', PageApiAccess::class, 'dashboardRequest'], ['DELETE', '{id:\d+}', PageApiAccess::class, 'pageIDRequest'], ['DELETE', '{path:.+}', PageApiAccess::class, 'pagePathRequest'], ['DELETE', '', PageApiAccess::class, 'dashboardRequest'] ] ]; You can use this class to get the page-outputs: <?php namespace ProcessWire; class PageApiAccess { public static function pageIDRequest($data) { $data = AppApiHelper::checkAndSanitizeRequiredParameters($data, ['id|int']); $page = wire('pages')->get('id=' . $data->id); return self::pageRequest($page); } public static function dashboardRequest() { $page = wire('pages')->get('/'); return self::pageRequest($page); } public static function pagePathRequest($data) { $data = AppApiHelper::checkAndSanitizeRequiredParameters($data, ['path|pagePathName']); $page = wire('pages')->get('/' . $data->path); return self::pageRequest($page); } protected static function pageRequest(Page $page) { $lang = SELF::getLanguageCode(wire('input')->get->pageName('lang')); if (!empty($lang) && wire('languages')->get($lang)) { wire('user')->language = wire('languages')->get($lang); } else { wire('user')->language = wire('languages')->getDefault(); } if (!$page->viewable()) { throw new ForbiddenException(); } return $page->render(); } private static function getLanguageCode($key) { $languageCodes = [ 'de' => 'german', 'en' => 'english' ]; $code = '' . strtolower($key); if (!empty($languageCodes[$key])) { $code = $languageCodes[$key]; } return $code; } } On top of your ProcessWire-template file you have to check if an api-call is active. If so, output JSON instead of HTML: <?php // Check if AppApi is available: if (wire('modules')->isInstalled('AppApi')) { $module = $this->wire('modules')->get('AppApi'); // Check if page was called via AppApi if($module->isApiCall()){ // Output id & name of current page $output = [ 'id' => wire('page')->id, 'name' => wire('page')->name ]; // sendResponse will automatically convert $output to a JSON-string: AppApi::sendResponse(200, $output); } } // Here continue with your HTML-output logic... That should be everything necessary to enable your ProcessWire-templates to output JSON. You will have an /api/page/ endpoint, which can be called to get the JSON-outputs. /api/page/test/my-page -> ProcessWire page 'my-page' in your page-tree under test/ /api/page/42 -> ProcessWire page with id 42 /api/page/ -> root-page And a small addition: If you want to query the page files also via api, have a look at my AppApiFile module. With it you can query all images via an /api/file/ interface.
  9. Hi @Jukka, I'm glad the module helps you build Apis for your frontend projects! Honestly, so far I'm not working on supporting caching solutions like ProCache. Not because I don't find it interesting or useful, but just because I don't have much experience with caching so far. Can you help me out with that? Maybe we can figure out together what the problem is or how the module would need to be extended to allow caching solutions to be docked without problems? Anyone else who is reading along here is of course also welcome to feel addressed :-) I am grateful for every advise!
  10. And now I got for you: Version 1.2.2 🤩 With @adrian's help I managed to find out, that the `date()` function in PHP 8 seems to return the current date, if NULL is passed in as the second parameter. In PHP 7 this was 01.01.1970 which was handled correctly. Long story short: Now I will write NULL to the database without any date-formatting. This should make AppApi fully compatible to PHP 8.
  11. I just released version 1.2.1. When testing with PHP version 8, some strange changes in the naming of header values occurred in my test environment, which meant that the values in the AUTHORIZATION header could no longer be read correctly. I have therefore made the handling of the header values a little more general in the new version, and implemented that certain prefixes are ignored. As a result, everything now runs normally again under PHP 8. How does it look for you? Have all the errors been solved? I can't rule out that things behave differently in other environments and with other server configurations. But I would like to take all possible deviations into account, so feel free to contact me if you notice any problems!
  12. @Pixrael What I do on ProcessPageView::pageNotFound is calling this function: public function ___handleApiRequest(HookEvent $event) { if ($this->checkIfApiRequest()) { // Check if the current REQUEST_URI starts with /api $this->apiCall = true; Auth::getInstance()->initApikey(); // Init authentication $router = new Router(); // Init Router $router->go($this->registeredRoutes); // Start resolving the route. This function will echo() and // exit() $event->replace = true; // Only needed in hook-function-call } } In theory (not tested yet), it should work to copy the three relevant lines (Init Auth, Init Router, Resolve Route) to your home-template file. I would be really interested to know if it really works out that way. Don't have time to test it out right now. This is my plan for a future module-update: - Extend the routes definition that it is not only applied to the api endpoint from the module configuration but to the whole pagetree - Check also on existing pages, not only in the 404 hook, if a route matches. If a valid api key is present, output the AppApi response instead. - Otherwise everything remains the same
  13. Hi @Pixrael! At the moment, this is not possible. In the AppApi module, a route must be specified that is not yet occupied by a classic ProcessWire route. AppApi uses a hook on 404 (Page not found) error and then replaces the return with the AppApi content. I am facing a similar problem right now. I would like to use ProcessWire exclusively as a headless CMS for an app. If you have access to the domain and subdomain settings, it might work to run ProcessWire under a subdomain and link the main domain to /api. However, I've been thinking for a while about how to add api responses to existing ProcessWire pages (e.g. the root page under "/").
  14. There was still a small problem that prevented the module from being automatically updated from within ProcessWire. I had renamed the root branch in Github from master to main, but then the download path in the ProcessWire module directory didn't fit anymore. Long Story Short: Now everything works again 🙂
  15. Sebi

    Twack

    Long time no see! I just released version 2.2.0 of Twack. With this, Twack now uses the new feature from the AppApi module (if installed) and registers its own route 'tpage' for page calls. This means that the JSON outputs of Twack components can now be requested easily through this Api endpoint: Route Description /api/tpage/ Calls the root page of the page-tree /api/tpage/42 Will call the page with id=42 /api/tpage/my/test/page Calls your page with path my/test/page
×
×
  • Create New...