benbyf

Hi HI David, in PW any function in a module that has ___ at the start, like ___handleApiRequest() in the AppAPI module you can use as a hook in your own code. See https://processwire.com/docs/modules/hooks/

$order = wire('pages')->get($data->id); echo $order // {} somehow I'm getting this when expecting string "order". PW 3.0.148

Hi @Sebi I added the log to app-api (will create a PR somepoint soon), I wondered if you wanted a log message on each request and maybe a setting in the modules settings to turn on or off, or maybe something more granular? My use case is going to require lots of log messages in the api files but having a generic log message on each request I though might be nice. Also wondered if it was worth making a second log for failed (exception) based log messages? so successful requests get logged to one and exceptions to the other..... any thoughts would be cool

Thanks both @Sebi and @thomasaull I appreciate your time. Will look into the log bug as thats paramount to us using the module so would be great to clear up. The non-apikey endpoints is more of a nice to have really as you can set up informational endpoints that act like website frontends but without the visual code obviously. In terms of users, applications and version, they seem loosely connected. There seems little reason to fill out the apikey version when creating a new apikey if it doesnt actually relate to anything. But maybe i just havent seen how it does or could relate. Also the users are too loosely associated with the applications (slight tangent), but it would be nice to leverage the user and roles system byt associating a user/s with either key or applications, and then auth them against them on route. e.g. [..., [route_options_role_required = "delete-pages, update-pages, create uses" ]] as the folowing api might enable these things and you wanna be pretty damn sure that user is allowed to do it 🙂

Thanks! @thomasaull I mean on the settings page the is a link to a log, which when clicked takes you to the logs overview page with an error saying the log you were trying to access doesnt exist. disabling auth doesnt create an open endpoint as you still need an apikey to access anything without an error sounds good but how do you implement this as there is nothing in the docs? ? cool beans, but my comment still stands 🙂

Sorry for all the questions ... Its not clear to me currently how version numbers or api keys or users are related and can be used to auth against a certain route... is that something we have to build into the api call to test the signed in user and their restrictions? be cool if this was tired into the auth stage/routes as you have all the parts there available but not tied together for some reason...?

Also, anyway to create a no apikey GET endpoint. could make this using templates but be nice it it was part of the same system

Hi @Sebi I saw that form_version associated with an aplication apikey doesnt get checked at all on request, is it worth adding it, when filled, to the routes... e.g. when blank route to /api/test when 1 route to /api/v1/test ?

HELLO! Some reason the log wasn't created for this module, wondered if this was something anyone had a view on or needed fixed. I'm running PW 3.0.148

HA! you do know what i mean then!!! 🙂 well I'll shut up then.

I guess in that case its solving the big content VS config divided present in all CMS's. But yes, i am cyrptic it seems. I guess my point was if I dont need the auto upgrading and downgrading that the module provides then I could not use it and simply write some template and field php code that you can cool as a "migration" as your module is a wrapper for quickly doing those tasks (exlcuding the uping and downing). In an ideal world the changes would be recorded in situ (no need to write them) and migrations would be exported to file to added to version control that can be ingested by any other PW install running the module. (I'm just all about writing less)

Am I right in saying that this module is less about migrations and more about automation? As using methods to do work using handy functions in a linear way sounds like automation to me, where as migration is something I want to do when I have a bunch of stuff that has happened to the environment that needs replication for some reason (i.e exporting and importing fomr staging to live). I only mention it as ideally you would work on your PW install (in the admin or in code) and at certain points take a migration of the changes... and therefore not need to hand write the migrations at all, as they're actaully artifacts of changes to the db? Bit meta, but I like using the admin, and would rather migrations were something that happened, not that needed writing. (this is coming from some experience with a migrations module in Drupal 6... yes i know! That did just as explained)

Running PW 3.0.165 and have added to config.php: $config->moduleInstall('directory', true); $config->moduleInstall('download', true); $config->moduleInstall('upload', true); but with no change in the admin... stil unable to update modules, or grab them via urls 😐 whats the deal here?

Thanks @B3ta - I feel like yours comments are somewhat off topic from this module specifically, so keen to get your feedback there if you have any. however, I do concur you thoughts on premium market place and there is actually a couple, one of which I started building myself then got busy and never got finished. It would be easier if we could all just use one central place, and easier for new PW users.

@B3ta possibly. what where you thinking? I’m mostly interested in input to help me, as it’s a bit rough Around the edges at the minute and wondered if anyone had feedback or PRs. I’ve recently done a lot more on it on a clients version which I’m looking to roll in soon, but am looking for enthusiasm for it so it’s not wasted work.