create a simple API for external use

[markkap]

call it render, and pass array of widget instance parameters

[DanielFloeter]

What is the different between the simple API and filter- and action hooks you implement in the premium version?

[markkap]

the API will be there as well. The difference is not in how things work,
but how they are being "activated" right now a user can add a widget or
shortcode, but this is a manual thing, and it is stored in the DB.

Storing configuration in the DB is bad when you have a dev and production
environment. If you add a widget in the dev enviroment you need to remember
how you configured it and do it on the production again. With shortcodes it
is even worse because they are part of the content and it is even harder to
sync them.
So a custom theme developer that does modifications for a specific site can
just call the API instead of adding widget, and have all the setting in the
code, and when the code is put on production there is no additional work
needed.

In a way, it is possible now to look at our code and call the shortcode
function to do it, but better to have something that is "official".

now that I think of it maybe we will need two functions, one of the header
to output the css and one to output the html.

The filters are not related for this, they will work the same way if it is
API widget or shortcode

On Fri, Oct 14, 2016 at 6:28 PM, Daniel Flöter notifications@github.com
wrote:

What is the different between the simple API and filter- and action hooks
you implement in the premium version?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#114 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABJnmnH_iyWiPcVSE5nWfa_5VM5Ljvh9ks5qz5-IgaJpZM4KW65A
.

[markkap]

not going to be as simple as I would have wanted as the CSS needs to be generated in the header so you either need two calls, one to do the CSS and another for the html. Instead I went with creating an object per widget which will "handle" the CSS side."automatically" and will need only a call to render the hml.

so the sequence is
somewhere...
$w = new virtualwidget($args)'
....
$w->renderHTML()

[markkap]

need some unittest.... but right now I have no idea what to test, otherwise the feature is complete

[DanielFloeter]

In short the API is to sync between widget instances?
If it's so, my aim is going in a UI to set one widget as master and others are the slave or a button to adopt the master settings.

Can we add a documentation how to use it and a list with the interfaces?

[markkap]

Not really to sync, the API is there for other people to create their own "widgets" based on our code..

I will write a blog post later this week and add documentation

[DanielFloeter]

What can a user change (with the "... created own widget ...")?
For example what he can't change with filter hooks.

[markkap]

User can not change. the users of of the API are theme developers that need
a way to insert the widget with zero configuration from the user

On Sun, Oct 23, 2016 at 9:58 AM, Daniel Flöter notifications@github.com
wrote:

What can a user change (with the "... created own widget ...")?
For example what he can't change with filter hooks.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#114 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABJnmgswQCTYI1h3F7p0LNfFx10fBfGXks5q2wV9gaJpZM4KW65A
.