wiki.getAllPages and dokuwiki.getPagelist differed in how the last
modification timestamp was communicated.
This should fixsplitbrain/dokuwiki-plugin-sync#70
This adds legacy support for the old API calls. This is mostly untested
but should work. Returns might not be 100% compatible in all cases but I
did my best to return the same things as before.
This will be removed in the future of course and is just to not
completely break any API usage immeadiately.
We test against the MockAPICore now since the tests are meant to ensure
the general functionality of accepting XML and correctly calling
APICalls works, not that the API returns the right things (this is
tested in the ApiCore tests).
Since we no longer use dates but always integers, we no longer need to
handle that.
When using named parameters, you can expect to be able to leave out any
optional parameter and have it take it's default, even when you specify
another "later" parameter. Luckily we already know all the defaults from
reflection anyway.
Instead of passing unknown arrays, explicit parameters are passed.
Revision handling should now work correctly since we can pass revision=0
but a mtime.
We always deal with timestamps or base64 now. Removing some of the magic
makes everything less complex.
Only affected plugin is confmanager, which needs an update.
Error codes are now extracted from API core and printed on the OpenAPI
overview page. This makes it easier to see what is in use.
Error messages have been cleaned up, some new codes have been assigned.
Some errors have been removed. Eg. it is fine to iterate a media
namespace you don't have read access to. The result will either be empty
or contain files from lower namespaces that you *do* have access to.
This only moves the calls. A proper refactoring of the user manager
would make sense:
1) introduce a helper component covering the basic operations including
proper error signalling using Exceptions
2) refactor admin and cli components to make use of 1)
3) make the operations in 1) available via the API
This cleans up the API:
* no more compatibility with obsolete wiki API
* no more difference between wiki.* and dokuwiki.* calls -> core.*
* use of optional parameters avoids double definitions
* use Response objects for complex results
* always use named primitives as input
* major cleanup of docblock descriptions
This introduces a new DocBlock parser to properly generate API
specifications. It also introduces the concept of Response classes to
better specify the response format.
This is still very much in progress.
This introduces an ApiCall class that wraps around the actual method
that produces the result. This replaces various loose array structures
that provided the meta information before.
The ApiCall streamlines the aggregation of meta information between core
and plugin methods. Now all data is produced by Reflection based
introspection. Certain aspects can be overridden if needed. See
ApiCore::getRemoteInfo() for examples
This change removes the _getMethods() method from remote plugins and
introduces a getMethods() method. The two are NOT compatible as the
latter now returns a list of ApiCalls. However when looking at the
existing plugins, it seems that _getMethods() was nearly 100% obsolete
with the Reflection based default implementation. So most plugins will
not be affected at all. Some might now export one or two more methods
than before because of poor visibility settings (eg. not declaring
private/protected methods as such).
This change removes the RPC_CALL_ADD hook. Only a single plugin ever
implemented it. I'm not sure what this hook was supposed to do anyway.
Being able to declare arbitrarily named API endpoints seems wrong to me
anyway.
The new ApiCall now also supports passing named instead of positional
parameters. This will open up a new opportunity to get a proper openapi
spec running.
Next step is fixing the tests.
Failed because positional parameters are not really possible to model.
Named parameter could be introduces when our minimum requirement is
switched to PHP8+
Andreas Gohr