pwFoo

I'll use user backend plugins. Default is PW users (add fields to save flarum credentials). Additional planned plugin is Flarum user backend (hook PW login and check via Flarum API call). First tests are fine. Syntax at the moment: Create a discussion // create a WireArray item, type "discussions" (= api endpoint) $res = $flarum->makeBlankItem('discussions'); $res->title = "My discussion..."; $res->content = "My demo content"; // new discussion will be created by a api call $res->save() Get discussions, filter a object by PW api and update it... // get discussions with pager (jsonapi filter is used) $wireArray = $flarum->discussions->get(array('filter' => 'page[size]=3')); // just use the PW api... $discussion = $wireArray->get('title=MyTitle'); // modifiy the object $discussion->title = "New title..."; // save to Flarum... $discussion->save(); Delete a user // delete a user by known id... $flarum->users->delete($id); // get users... $flarumUsers = $flarum->users->get(); // all users // get one user by ID | username $flarumUser = $flarum->users->get(array('id' => $userId); // by userId $flarumUser = $flarum->users->get(array('id' => 'MyUsername'); // by username // delete a user object $flarumUser->delete();

Take a look at docker-gen (https://github.com/jwilder/docker-gen) and nginx-proxy (https://hub.docker.com/r/jwilder/nginx-proxy/). Docker-gen needs access to the docker socket. Because of the exposed proxy ports (80,443) I build two separated containers. Just replace nginx with caddy. The revProxy (docker-gen, caddy) helps to work with multiple webspaces / hostings, SSL and ssl offloading. If you add / remove webspaces caddy proxy will be notified and update the Caddyfile. A webspace is based on different linked containers (webserver, php-fpm, persistent volume). Because of memory usage I use a global MySQL container instead of a own container for each webspace.

It could also used as docker http/s reverse proxy with ssl offloading. No need to renew and replace certificates. With a second container (docker-gen) the Caddyfile will be generated / updated and the server process notified to reload. First test works (with generated Caddyfile, but at the moment manual reload).

Yes, your rewrite works, but with the next release it should be replaced with to {uri} {uri}/ /index.php?it={uri}&{query} We'll see

I try to integrate Flarum forum with PW via JSONAPI. First tests are fine (register user, create discussions, get data, ...). To get a valide token I send the username and password as a api call. If auth was successful I'll get the uid and a token back. This token have to be renewed after 30 minutes. To get the token I need username and (plain!) password. So how should I save the user credentials / handle the users? Just additional fields in the user profile username, password, token and uid as array (serialized + base64 encoded) Sync PW users with the remote app (hook PW auth and send a auth request via API call -> token returned = login OK) 1 and 2 would be flexible, but user credentials are saved as plain text! 3 is a secure solution (no plain credentials needed), but PW have to use a remote user backend / auth and maybe some things could be less flexible... Do you see any problems with that solution? Could it break features / modules?

Strange... reinstalled. Created a simple test module and it works fine.. Haven't found the mistake, but seems to be caused by my code Thanks for help with a test, Teppo!!!

Image upload could be the following 500 error? "POST /index.php?it=/admin/page/edit/&id=1004&InputfieldFileAjax=1&{args} HTTP/2.0" 500 228 No time to take a closer look yet... But looks PW@caddy seems to be fast Caddyfile https:example.com { root public_html fastcgi / 127.0.0.1:9000 { # ext .php .module ext .php } internal /forbidden rewrite { r /\. to /forbidden } rewrite { r /(COPYRIGHT|LICENSE|README|htaccess)\.txt to /forbidden } rewrite { r ^/site(-[^/]+)?/assets/(.*\.php|backups|cache|config|install|logs|sessions) to /forbidden } rewrite { r ^/site(-[^/]+)?/install to /forbidden } rewrite { r ^/(site(-[^/]+)?|wire)/(config(-dev)?|index\.config)\.php to /forbidden } rewrite { r ^/((site(-[^/]+)?|wire)/modules|wire/core)/.*\.(inc|module|php|tpl) to /forbidden } rewrite { r ^/(site(-[^/]+)?|wire)/templates(-admin)?/.*\.(inc|html?|php|tpl) to /forbidden } # GLOBAL rewrite { r .* ext / to /index.php?it={path}&{query} # to /index.php?it={path}&{query}&{args}#{frag} # to /index.php?it={uri}&{query} # to {uri} {uri}/ /index.php?it={uri}&{query} } log logs/access.log { rotate { size 50 age 7 keep 5 } } errors { log logs/error.log { size 50 age 7 keep 5 } } } Next release will have some improvements to replace like that to {uri} {uri}/ /index.php?it={uri}&{query} => file if exists OR directory if exists OR rewrite to index.php... Maybe some PW directories should be moved to make htaccess file / nginx | caddy rewrite easier and much shorter (disallowed directories could be moved to a sub directory?).

Hi, I read the blog articles and many planned improvements and new features. At the moment I do some tests with devns branch and maybe switch over to it. ProcessWire's front-end framework (for the admin) I like the PW backend. It shouldn't be more complex or slower. Simplify it and maybe reduce dependencies (jQueryUI?) to make it faster. If modules like inputfields (frontend file uploads), login (swap out backend admin messages), .... will be modified it would be great to keep frontend usage in mind. I know that isn't the PW intention, but it would be great to reuse login module, form api... Other systems deliver "basic modules" like login, register while developers have to write custom code or use 3rd party modules. I like to write my own modules and learn more about PW, but more stable frontend useable modules (= existing core modules used in the backend) would make PW more attractive for new users and could increase the community.

Hi, after sone time playing without hooks I tried to hook the WireHttp method send() with the latest devns (send is now public and hookable!), but it doesn't work. What's wrong with this call inside a module? $this->addHookAfter('WireHttp::send', $this, 'hookCheckAuth'); Inside the "hookCheckAuth" I tried to echo, exit() / die() or modifiy $event->return. Works if I call the method direct, but nothing happens if I call the WireHttp send() method...? Tried it also from a template and it works with the following code: wire()->addHookAfter('WireHttp::send', function($event) { die("TEST"); }); Same code modified to use it inside a module doesn't work: $this->addHookAfter('WireHttp::send', function($event) { die("TEST"); }); $this->wire()->addHookAfter('WireHttp::send', function($event) { die("TEST"); }); wire()->addHookAfter('WireHttp::send', function($event) { die("TEST"); }); I'll reinstall PW to have a clean new install... But maybe I missed something... *UPDATE* Also tested without success: $wire->addHookAfter('WireHttp::send', function($event) { die("TEST"); });

At the moment I do some tests with a jsonapi and wrote a simple client before I found the WireHttp module: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/WireHttp.php jsonapi needs also PATCH (edit, update) and DELETE method. I opened an issue at github for that. Maybe Ryan could add these two methods. WireHttp isn't hookable. That was my second feature request, because it would be great to hook into the module to check response and renew the api token if needed. patch() and delete() could be added as hook or by extend the WireHttp class, but added as native feature would be great. Anyone use the WireHttp class? I wrote a simple module to handle api requests before I found the WireHttp class. Would you recommend to switch to the WireHttp or use a custom json api module (based on file_get_contents() for example)?

Hi, I think my function arround find() is the problem. So find() should work with custom WireArrays. I'll test it soon...

I found Caddy a short time ago and it sounds really interesting. If I have some time I also will start tests. Maybe it could be useful for some setups / sites Extensions are also nice https://caddyserver.com/docs/git

Mh, I build an custom module to fetch json data from an jsonapi and convert it... now I found your post and the wireDecodeJSON function...

Hi, I build a new module and try to convert data into WireArray to get the PW API benefits (find('selector'), get('selector'), ...). Some code to my tests... Define a custom WireArray class class CustomWireArray extends WireArray { public $toStringString = ''; public function __toString() { return $this->toStringString; } public function __get($key) { return $this->$key; } public function __set($key, $value) { $this->$key = $value; } } Create a new CustomWireArray $customWireArray = new customWireArray(); Create a new array item $item = new customWireArray(); // set properties to $item... $customWireArray->add($item); // add to the customWireArray So far it works fine. No problem to find() / get() properties from the $customWireArray, but I need sub-items Tested it with a sub-customWireArray and also a simple stdClass, but it won't work with PW find() / get(). Is there a way to get sub-properties work with something like that? $result = $customWireArray->find('property.subfield=MyValue');

I started an Flarum integration module. Predefined and also custom API calls are supported. "data" and "included" objects are converted in PW WireArray and supports PW API like find() and get(). http://flarum.org/docs/api/ http://jsonapi.org/examples/ At the moment unencrypted username and password is needed to get an token for logged in api calls.

I tested FrontendUser module with PW 3.0 dev and it seems to works fine, but minimal changes to FormHelper are needed because of namespace compatibility... The FrontendUserRegisterEmailValidation plugin send an empty mail body and a update is needed to make it work with PW 3.0! Maybe I'll optimize my modules for the PW3.0dev usage soon. FormHelper PW 3.0 dev compatibility: https://processwire.com/talk/topic/7860-module-formhelper/?p=108577

Done a short compatibility test to PW 3.0 dev and it seems to work with a minimal change because of php namespace to get it work by the PW 3.0 module compiler. File: FormHelper.module Replace all "hookEvent $event" with "$event" Maybe I'll optimize my modules for the PW3.0dev usage soon.

Hi mr-fan, thanks for creating the github repo! I think You should add the PW version OfficeSuite is built / optimized for.

My approach works with a page "tags" (or categories... as you want, also sub categories are possible) and a page "topics". All children of tags are used to build the forum structure (page reference) and replies are saved as children pages of the topic page. So forum structure is separated from the forum contents (topics and replies) which was important for me. And all contents (topics and also replies are just pages (do you use the comment module or also pages for replies?).

Maybe EsoTalk and particularly its successor Flarum could be inspiration. I started such a basic discuss module (just some code for testing, nothing which could be used yet) but stopped it because of lack of time.

My stopped "discuss" module was as simple as possible. The base module was planned without an admin / moderator panel and it should just take care about add and edit (own) posts and a structured view (EsoTalk / Flarum like discussions, also with user based view permissions for private topics instead of private messages). At the moment I haven't started an Flarum integration (no time and it's beta), but it could be interesting in the future. HermodBB could be interesting, but strategic focus should be the frontend and usability (at the beginning PW backend would be fine to administer / moderate the boards and posts). My key features tag based structure instead of categories / page tree private conversations by tagging topics with allowed users (or groups?) ajax notifications (PW notifications module?) about new replies and changes in the actual view All other stuff ("like" feature, backend, ...) should be added as optional extensions / plugins (PW hooks)

Hi, the module is listed as unstable because I don't use it with a production site at the moment and there isn't that much feedback about production usage yet, but I think some members here are using it. Reported issues should be fixed. The module IS designed as a starting point and easy to extend by writing plugins (based on PW hooks) without hacking the module itself. *UPDATE* You plan to build a PW based forum? https://processwire.com/talk/topic/11201-hermodbb-basic-bbforumcomments-module

Could you post your complete template file, please? With this simple line I get a form with all fields of the template. $fcm->add($pages->get('title=my-page-title')); // OR //renderAdd is a shortcut for add() + process() + render() $fcm->renderAdd($pages->get('title=gfh')); Get page by ID should also work (it needs a page object). The other params are optional. Short edit / add tests with my dev setup show all the form fields. Form should be processed and rendered before you output the results.

Thanks Luis!

I started a short time ago with own modules and my first git repo. Would someone with more experience manage the git repo? I could create a repo and push the code, but don't know if I'm able to maintain / support it...