Sebi

Hey @spoetnik, sorry for the delay. I finally found time to look a bit deeper into it... I have good news and bad news about XHTML. Bad news: As automatically as I described in my last post, it will not work in Twack to include XHTML support. Each component compiles its own HTML output in the view. The components can be nested and integrated in different places in the layout - it would not be expedient for Twack to intervene automatically and simply not render certain components or something. The good news, however, is that you should be able to integrate XHTML support with the existing logic without any problems. For example, you can come up with a GET parameter yourself that ensures that only a certain part of the page is rendered in your view. In order to make the whole thing a little easier to organize, I have just released a new Twack version 2.3.0 with a list feature. You can now also manage the child components for each component in so-called componentLists (e.g. header components, footer components, sections, ...) and output these lists in the appropriate places in the HTML layout. For XHTML, for example, it would be conceivable to output only the HTML of the header components with a ?show-only=header GET parameter. I've added a example in the named-components section at the wiki: https://github.com/Sebiworld/Twack/wiki/6:-Named-components

Hey @spoetnik, thank you for your input! I think Twack's base with its component structure could be a good foundation to fit HTMXs needs, but I am a little worried about opening security gaps. It is certainly possible to build a function that can be used to get each individual Twack component back individually. But we have to make sure that no access-protected information becomes accessible. I usually control the access authorizations on the ProcessWire page - individual components cannot be easily controlled. A good approach could be to request the page as before, but to provide a kind of identifier that ensures that only the subcomponent with this ID can generate an output from the component tree. As a result, the access rights would continue to be active as before and no output can be obtained via the HTMX request that would not already have been contained in the classic request with the output of the entire page. But I'm still not really sure whether this is the best solution for this feature.

Big news! Version 1.3.0 is out - the big documentation update! The new version will activate a new view in the AppApi UI under Setup->AppApi. The button "See endpoints" will lead you to a new overview page which lists all registered api-endpoints. That includes the default /auth endpoints from AppApi, your custom endpoints from routes.php and all endpoints that were registered by a custom api-module like AppApiFile. I found it useful to see where the handler-functions for each endpoint are located, so I included that as well. And wait, there is more: The overview page has a button to auto-generate an OpenAPI 3.0.3 json, that can be imported in tools like Postman or Swagger. And you are now able to add documentation details in the routes definition, to make the generated json even more powerful. Read more about this in the new wiki-chapter. I have worked some time on this new feature and hope that it will bring much joy into your api-developer lifes ☺️ (Please consider buying me a coffee if you like my work)

I have just released the newest version 1.2.8 of AppApi. No breaking changes, but it should fix an issue that could lead to installation-errors when the used MariaDB version does not support JSON as db column type. Additionally I have included some bugfixes to the email-authentication logic.

Oh wow. Thank you @Robin S! I've been looking for way too long, but I didn't come up with that. My AppApi module does not have the problem because it has Process extended. For that it even says in the documentation that parent::___install() has to be called. But for my simple module that only inherits from WireData, parent::___install() makes no sense. Thanks a lot!

Hello! I'm debugging for a few days because I noticed that my modules can no longer be installed without errors. If there is a ___install function in my module, an error is thrown when installing the module and the code in the ___install function is not executed. I am sure that it worked, because AppApi uses that function to initialize all database tables. Here is the code of a simple test-module that is not installable without errors anymore: <?php namespace ProcessWire; class TestModule extends WireData implements Module { public static function getModuleInfo() { return [ 'title' => 'My Test module', 'summary' => 'An example of creating a module', 'version' => 1, 'author' => 'Sebastian Schendel', 'icon' => 'user-plus', 'requires' => [ 'PHP>=7.2.0', 'ProcessWire>=3.0.98' ], 'autoload' => true, 'singular' => true ]; } public function ___install() { if (!parent::___install()) { return false; } return true; } } These errors occur for example: Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 262144 bytes) in /processwire/wire/core/WireHooks.php on line 912 Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 262144 bytes) in Unknown on line 0 I have tested a ProcessWire version from a few weeks ago and the newest 3.0.212 dev. The error occurs in both versions and I do not know how long its present already... Tested with PHP 7.4, 8.0 & 8.1, too. How do you initialize your modules after install? Am I missing something here? ?

Hey @Jukka, I finally got some spare time to set up a select field in my test environment. This is my static function, that is called my Routes.php: public static function fieldTest($data) { $page = wire('pages')->findOne('id=8226'); return [ 'selectedValue' => AppApi::getAjaxOf($page->test_options) ]; } My SelectOption field is called "test_options". Calling the route returns the following JSON: { "selectedValue": [ { "id": 3, "title": "My Test Value", "value": "" } ] } That is the item that I've selected on my test-page. It's also possible to get the title via `$page->test_options->title` and the id via `$page->test_options->id`. Is the id the "value" that you expect? I did not work with SelectOption very much, so please excuse the maybe stupid question ?

Hey @Jukka, I don't know when I find time to test that out, but can you maybe try if deactivating the URL hook in the AppApi module settings helps? I had problems with reading values of SeoMaestro when the "new" hooks were activated. Maybe its something related...

Hi @Frank Vèssia, I finally found time to recreate this once in my test environment. Unfortunately, I cannot reproduce the error. My routes definition looks like yours: $routes = [ 'v' => [ '1' => [ 'category' => [ ['OPTIONS', '{slug:\S+}', ['GET']], ['GET', '{slug:\S+}', AppApiTEST::class, 'getCategory'], ] ] ] ]; When I simply dump $data->slug, I get the full "variety" slug when calling the /v/1/category/variety url: class AppApiTest { public static function getCategory($data) { $data = AppApiHelper::checkAndSanitizeRequiredParameters($data, ['slug|pageName']); var_dump($data->slug); die(); } } Can you try out if maybe my latest v1.2.6 update, where I improved the route-merging logic, fixed the issue for you? Or could it be something else which is special to your environment (PHP version? Modules or hooks, that could interfer with the AppApi handlers? Maybe it helps to deactivate the new ProcessWire URL Hook in AppApi's settings?)

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? ?

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! ?

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!

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!

@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.

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.