Sebi

Hi @David Lumm, I'm workung on an emergency fix. Still cannot reproduce the problem, but I will try to change the datatype of the default_application-column from boolean to int. Hopefully that fixes it.

Hey @David Lumm, thanks! Short answer: Yes, I'm pretty sure that upgrading to 1.1.0 will not break anything. Longer answer: Every previous functionality will work as before - there are only additional features, but no breaking changes. During the update the module will add a new column "default_application" to the appapi_applications table. Everything else stays the same. To be on the safe side, I tested upgrading to 1.1.0 and new installing in multiple different configurations. Besides @derixithy 's comment above I did not hear any problems. But if against all expectations you notice something, feel free to contact me ?

Hey @derixithy, I've just set up a new ProcessWire-instance (current stable 3.0.165) and installed the module. Everything seems normal and I can add applications without getting an error. Maybe it is a problem with your individual configuration, can you give me additional details (e.g. ProcessWire-version, was AppApi installed before and updated to v1.1.0, or is it a fresh install? What PHP-version do you run?) The following is the INSERT-statement I use to create a new application in db: $createStatement = 'INSERT INTO `' . AppApi::tableApplications . '` (`id`, `created_user_id`, `created`,`modified_user_id`, `modified`, `title`, `description`, `default_application`, `token_secret`, `accesstoken_secret`, `authtype`, `expires_in`) VALUES (NULL, :created_user_id, :created, :modified_user_id, :modified, :title, :description, :default_application, :token_secret, :accesstoken_secret, :authtype, :expires_in);'; So let me try to interpret the error message... "Invalid datetime format: 1366" - 1366 looks like a user-id, that should be used as variable :created_user_id. But it tries to insert that value to a datetime-column, which could be the 'created'-column that follow right after that in the insert-statement. So it looks like that something went wrong with the variable-values for the PHP-prepared statement I use. You find the create-statement here in the code: https://github.com/Sebiworld/AppApi/blob/65911a3f13c6420ffad0e68b34d8c51a8b1eb99c/classes/Application.php#L614 Have any of you ever seen anything like this?

Just released version 2.1.4 with an improved documentation. I moved most of the contents from README.md to the repository-wiki. Everything is better structured and more readable ?

Thank you @3fingers ! Your coffees will help me to stay motivated ☺️

@thomasaull is right. I have added an example in the Wiki, in which I demonstrate the output of a RepeaterMatrix-field "contents" that I use in most of my projects: https://github.com/Sebiworld/AppApi/wiki/3.1:-Output-Formatting#complex-data I hope, that helps. Generally speaking, you can output anything you want via api. You only have to transform complex structures like ProcessWire-Pages, Repeatermatrix-fields, ... into something that is JSON-encodable.

Merry Christmas everyone! I hope you have some peaceful and calm days! ? If you've been keeping an eye on the commits in the meantime, you'll have seen some progress for the upcoming version 1.1.0. The current status in the develop branch should be as good as finished in terms of programming. Only the readme has not yet been adapted. I want to move large parts of it to the repository wiki and then add more examples. If you have some time, I would be very happy if you could test the new features (develop-branch). What's new: Improved AppApi-dashboard Allow multiple levels to routing config (by @David Lumm, thanks for PR ?) Allow requests without an api-key: You can now mark an application as "default application". If you did so, every request without an apikey will be linked with that application. You can now set a custom response-code in case of success. Simply include your response-code number on key "responseCode" in your result-array. For example my test-function, which is called on a route in Routes.php: <?php class AppApiTest { public static function test($data) { return [ 'success' => true, 'responseCode' => 202 ]; } } Optional access-logging: You can enable access-logging in the module's configuration. After that, every successful request will be logged with it's application-id, apikey-id and token-id. Added hooks to all essential functions - that should enable you to customize the module's behavior even more. E.g. you could add custom logging on a hook, if you need that Database-scheme does not need foreign-key constraints any more. That should fix @thomasaull 's issue with db-backups. After the update, you must remove the constraint manually because I did not find a way to remove the foreign key safely in all database-environments. Multiple other bugfixes What do you think? I look forward to your feedback!

Hi everyone! I just wanted to give a quick sign of life. The time of Christmas vacation is finally reached and I can finally invest time in open source project again. Thanks a lot for your input. In the next days there will finally be an update for the AppApi module. I would then like to provide you with a development state for testing before a new master version is released. Let us list the feature-requests: Error when importing database dump: Cannot add foreign key constraint (by @thomasaull) Multi Language and ProCache do not work Weird HTTP status responses (by @David Lumm, thanks for PR ?) [Feature] Add multiple levels to routing config (by @David Lumm, thanks for PR ?) Optional extended logging like @benbyf said earlier. Created Issue #10 on Github so I don't forget it. I will look into the other bugs and issues discussed here as well. Did I leave something out? Thank you for your help and stay tuned for the next updates!

I'm here! ? Hi @benbyf, I'm glad that your using AppApi! Let me clear this up a little: 1. It's a bug, I am linking to a protocol named 'app_api' in the module's settings, but the actual logs are written in a log named 'appapi-exception'. I will create an issue for that... 2. @thomasaull is exactly right. Currently there is no way to connect to the api without an api-key. It is necessary, because the key is needed to identify which application-configuration should be used. I am definitely planning to make it possible to define a "default"-application, that handles requests without an apikey, but it will need some time...an 3. I would generally create new apikeys, even for small version-steps. If you need to block an old version, you can set the accessable-until field of the apikey or simply delete it. What I don't fully understand is what you mean by "form_version", @benbyf. You can define an endpoint api/v1/test and api/test and let them handle requests from different versions. But the module does not automatically handle versions, add v1 to your path or something like that. Maybe you can specify what you are trying to achieve here? Lastly, I must honestly state, that I am very busy with a very time-consuming project at work, which is why I do not find much time to work on module-updates. It will probably take until Christmas until i can put time into the project again. So if you understand the module's internal logic, I would be thankful for your pull-requests...

Recently i have released the new version 1.0.4 of AppApi. In this version I use ProcessPageView::pageNotFound instead of the previous used ProcessPageView::execute hook. This hook is triggered later in ProcessWire's boot process, which should allow features like multi-language fields and other modules to initialize before the api tries to access their values. Let me know, if it worked for you! Besides that you can now configure the path to the Routes.php file, that is located under site/api/Routes.php per default. If you need to have it somewhere else, you can set any location (relative to ProcessWire's root directory) in the module's settings. Thanks to @thomasaull and @spoetnik for supporting me with issues and comments in the AppApi Github repository!

I tried it out and could reproduce the error in my configuration as well. The problem here is not your $page that you want to delete. The problem is, that $this->wire('page') is null, because you requested no special page which processwire can use as its current page. I would consider that as a processwire-bug, it could easily prevented by adding a check if $this->wire('page') contains a page. What do you think? Maybe @ryan can add something to it? Nevertheless, I would like to suggest something about your code example. Please be aware, that you must make sure, that only valid page-ids will be accepted and only valid client-pages will be deleted. If I send a request with an id like 0, I could try to delete the root-page if I want to. Please check everything, that comes from an api-request and sanitize these values. This is how I would do it: public static function deletePage($data){ if (!property_exists($data, 'clients')) { throw new \Exception('No clients found', 400); } foreach($data->clients as $client) { if ($client->changeType == 0) { if(!property_exists($client, 'id')) { continue; } $p = wire('pages')->get(wire('sanitizer')->int($client->id)); if(!$p->id || $p->template->name !== 'client') { continue; } wire('pages')->trash($p); } } }

I'm not sure, if I understand you right: Do you want to trigger an api-call on a different hook? Do you have an example, maybe a code-snippet, how you would do it? What I like on the current way is, that you do not need to create a page or a file in the templates-directory. So you can have a complex existing site, install the module and the module would work without the need to change something in the pagetree. But that can be only a matter of opinion, I think that other ways would also have advantages. I'm currently trying out a multi-language site and will give you an update if I could find a practicable way to implement this. My experiences with caching are, to be honest, very limited so far. So if anybody knows about it and could suggest improvements, that would be great! I think I can make the path to api-routes easily configurable, so it can be moved to /templates if the user needs it there. I think that could be solved by some kind of default-application, that is called if no api-key is found in a request. It's a little complicated, because the module needs the api-key to choose the corresponding application. Apikeys bring a bunch of benefits, which a default-application without an apikey cannot have. We would not be able to block old apikeys. We make it easier for bots to scrape our page. And it could be confusing, when we just forget to add the apikey-header and will be sent to the default-application without an error. I would consider that as a future improvement, but I think it needs some more thought before implementing it. So, thanks again @thomasaull for your comments. Can you please make issues on Github out of this?

Hi @thomasaull, nice to hear that you like what I did to your module ? I would really appreciate it if we could work together on the next developments. For my projects a good and flexible Api connection is very important. Therefore I hope that we can improve the module even more. So, let me answer your comments one after another: if ($last_error && $last_error['type'] === E_ERROR) { Consider that as fixed. I just pushed version 1.0.3 with a few documentation-fixes and this bugfix. Thank you for this hint! I activated Github-Issues for the repository as well. I think, issues and/or pull requests on Github will be a better way to work on new features and bugfixes, since this forum-post would become long and more and more confusing. I additionally contacted Github whether it is possible to remove the fork-connection to your RestApi-repository.

I really like to use Insomnia testing api-calls. It's a stand-alone tool for Mac, Windows and Linux. And the free plan suits perfectly for all my needs - the paid functions are primary focuses on collaboration features for teams.

Hi @Krevolution, glad to hear that you could solve the problem by yourself. I'm the author of the AppApi-module your using. If you encounter more problems or questions regarding AppApi, feel free to mention me via @Sebi. That makes sure, that I get a notification about it. Anyway, I am pleased that you use the module!

Good news! We are live now! AppApi has been approved and now appears in the modules directory: https://modules.processwire.com/modules/app-api/ Thank you for your many reactions to the release - I hope it helps you build the best apis you can imagine!

I have exciting news for you: ? For the release of my module AppApi I have now also finished the section about the Ajax output of Twack. Twack and AppApi work together perfectly. The routing and authentication is done by AppApi. Twack can also render JSON instead of HTML-views. Here you can find out more about routing with AppApi: https://github.com/Sebiworld/AppApi#example-universal-twack-api And here is the description of the Ajax (JSON) output of Twack components https://github.com/Sebiworld/Twack#ajax-output

Hello friends! I have another module for you, which will make your daily work as a Processwire developer easier. Introducing: AppApi This module helps you to create api-endpoints, to which an app or an external service can connect to. Features Simple routing definition Authentication - Three different authentication-mechanisms are ready to use. Access-management via UI Multiple different applications with unique access-rights and authentication-mechanisms can be defined The documentation has become quite extensive, so have a look at the Github repository for details: Installation Defining Applications Api-Keys PHP-Session (Recommended for on-site usage) Single JWT (Recommended for external server-calls) Double JWT (Recommended for apps) Creating Endpoints Output Formatting Error Handling Example: Listing Users Example: Universal Twack Api Routes Page Handlers File Handlers A special thanks goes to Thomas Aull , whose module RestApi was the starting point to this project. This module is not meant to replace this module because it does a great job. But if you want to connect and manage multiple apps or need other authentication methods, this module might help you. I am already very curious about your feedback and would be glad if the module helps you a little bit.

I have now, as promised, a new version ready for you. Version 2.1.3 includes the improvement that @bernhard suggested. Twack is now available as api-variable. I personally prefer the wire('twack') syntax, but that's a matter of opinion. All code-examples and the project`s readme.

Hey @bernhard, that looks like a useful improvement. I actually didn't know that it is possible to register API variables. I will provide a module update in the next days - thank you for your support!

Hi @Roych, sorry for my late response, I am currently a bit busy at work. The musical-fabrik repository is the main code for the page https://www.musical-fabrik.de , but there are several additional requirements (processwire's core, modules like PageTable and Repeatermatrix and the database-contents) to get the site running locally. Unfortunately I cannot make everything public, so I would recommend you to start a blank site and try to start building a simple component like shown in Twack's readme. The musical-fabrik page is an example, where everything is built out of nested Twack-components. You can see that in the php-files under /site/templates/, for example site/templates/default_page.php: <?php namespace ProcessWire; $twack = wire('modules')->get('Twack'); $general = $twack->getNewComponent('General'); echo $general->render(); This file is called, when a processwire-page with the template default_page is called. The only thing we do here is loading the Twack-module, initializing the General-component (located under /site/templates/components/general/) and then rendering it. The general-component renders the basic html structure, adds a header and a footer, and adds the default_page component as the main content area between header and footer. default_page registers itself under the global name 'mainContent', which can be used from everywhere else to add content-components to a page: $this->twack->makeComponentGlobal($this, 'mainContent'); Because of that, the galleries_container-template can add a gallery-grid under the default contents: <?php namespace ProcessWire; $twack = wire('modules')->get('Twack'); $general = $twack->getNewComponent('General'); $content = $twack->getComponent('mainContent'); $content->addComponent('ContentGalleries', ['directory' => 'contents_component', 'title' => '']); echo $general->render(); I hope, that helps to basically understand the underlaying logic of the site. Twack does not force you to use it that way, you are free to structure your components in many other ways. I am currently working on the documentation for the ajax-functionality, that lets you render every component as an json-array instead of html, which makes it very useful for app-api-development as well. Maybe, if you are interested, I could starting to write tutorials for some special Twack-components (like a simple header, footer, ...). The contents-component and my form-component, that builds a bootstrap-html-form from any processwire-template could be useful as well. Feel free to ask if something is unclear, I am aware that it can be hard to understand the concepts of Twack. But I am also convinced, that it is a great way to structure processwire projects. Thank you very much for your interest in it!

Since it's featured in ProcessWire Weekly #310, now is the time to make it official: Here is Twack! I really like the following introduction from ProcessWire Weekly, so I hope it is ok if I use it here, too. Look at the project's README for more details! Twack is a new — or rather newish — third party module for ProcessWire that provides support for reusable components in an Angular-inspired way. Twack is implemented as an installable module, and a collection of helper and base classes. Key concepts introduced by this module are: Components, which have separate views and controllers. Views are simple PHP files that handle the output for the component, whereas controllers extend the TwackComponent base class and provide additional data handling capabilities. Services, which are singletons that provide a shared service where components can request data. The README for Twack uses a NewsService, which returns data related to news items, as an example of a service. Twack components are designed for reusability and encapsulating a set of features for easy maintainability, can handle hierarchical or recursive use (child components), and are simple to integrate with an existing site — even when said site wasn't originally developed with Twack. A very basic Twack component view could look something like this: <?php namespace ProcessWire; ?> <h1>Hello World!</h1> And here's how you could render it via the API: <?php namespace Processwire; $twack = $modules->get('Twack'); $hello = $twack->getNewComponent('HelloWorld'); ?> <html> <head> <title>Hello World</title> </head> <body> <?= $hello->render() ?> </body> </html> Now, just to add a bit more context, here's a simple component controller: <?php namespace ProcessWire; class HelloWorld extends TwackComponent { public function __construct($args) { parent::__construct($args); $this->title = 'Hello World!'; if(isset($args['title'])) { $this->title = $args['title']; } } } As you can see, there's not a whole lot new stuff to learn here if you'd like to give Twack a try in one of your projects. The Twack README provides a really informative and easy to follow introduction to all the key concepts (as well as some additional examples) so be sure to check that out before getting started. Twack is in development for several years and I use it for every new project I build. Also integrated is an easy to handle workflow to make outputs as JSON, so it can be used to build responses for a REST-api as well. I will work that out in one section in the readme as well. If you want to see the module in an actual project, I have published the code of www.musical-fabrik.de in a repository. It runs completely with Twack and has an app-endpoint with ajax-output as well. I really look forward to hear, what you think of Twack?! Features Installation Usage Quickstart: Creating a component Naming conventions & component variants Component Parameters directory page parameters viewname Asset handling Services Named components Global components Ajax-Output Configuration Versioning License Changelog

Hi @MateThemes, ProcessWire allows you to have any custom folder you want in its root, so you can leave your cam-directory where it is. The path to the images will stay the same. So, if you included an image with <img src="/cam/someimage.jpg"/> before, you do it just like that in your processwire-template file. Just a small restriction to notice: You must not create a page with "cam" as path in processwire, because that will block access to your folder.

@flydev In my version, BasicAuth is the preferred way to request a jwt-token. After that, you have to add the token to each request.

Hello everyone, while building an app-interface for a page, I developed some changes and improvements to this module, which I made available as a pull request. But @thomasaull and I are not quite sure if it makes sense to transfer these basic changes into the main module as well. Therefore we would like to hear your opinion: What do you think of the new module version? Which features would be useful for you? I have developed several new features that allow the administration of Api accesses via the ProcessWire backend. I also revised the authentication and added a new Double-JWT option that works with long-lasting refresh and short-lived access-tokens. New Features: New menu item "Restapi" in the ProcessWire menu under "setup Management of Api accesses (applications) outsourced to the new menu item Apikeys now authorize api-access Creation of multiple applications with different auth types possible Double-JWT Authentication, renewable tokens token-sessions can be viewed and deleted in the backend Improved exception handling: Each endpoint can throw exceptions, which are then output with the appropriate HTTP status header and message.