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.

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

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.

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!

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.

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!

@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

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 "/").

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 ?

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

Hey @Red_nipon! Nice to have you here! Can you please explain this in more detail? What exactly do you want your client to be able to do? As I understand it, the customer gets a login from you for the ProcessWire admin interface and can then publish one or more SPAs there themselves with their own configuration. Then it would make sense to create a ProcessWire template for it with the configurable parts (fontcolor, dates, ...) as fields. If you or the customer then create a new page with this template in the pagetree, it can be called in the frontend. Of course you can also put a javascript file from a SPA into the corresponding template PHP file and just let PHP write the few configuration parameters into a <script> area, which the SPA then reads when loading. That would be the simplest way I can think of. This concept isn't strictly "headless" then, but it doesn't have to be, does it? Headless to me would be an approach where the ProcessWire resides somewhere else and completely independent of the frontend. I'm actually working on an SPA with Angular/Ionic right now as well. The javascript application is at a hoster under its own domain, the ProcessWire backend is somewhere else entirely. I really like ProcessWire and have already done a lot with it, so it was my first choice as headless CMS for my project. If there are better headless alternatives I can't tell you, only that it works well with ProcessWire. The SPA then constantly requests data (e.g. a configuration, the contents of lists, blog articles, users, ...). The AppApi module is very good to create a JSON api for this [Disclaimer: I am the author of this module :D]. But if you don't need such a constant data exchange, this concept is probably much too cumbersome...