GeeklogWiki - User contributions [en]

Cross Site Publishing and Receiving Information

2010-08-16T21:49:38Z

TimPatrick: /* Introduction */

= Introduction =

The Cross Site Publishing and Receiving API and GUI (Referred to as `CSPR` from here on) allows plugins to accomplish the following:

* Publish and receive any type of data among not only Geeklog sites but any application (web or desktop) that support the ATOM protocol and implement the REQUEST commands.

Using the CSPR is extremely easy, and all work can usually be done in a few API calls (for integrating support) or in a few clicks (using the GUI).

'''NOTE: This guide is IN PROGESS so until this message is removed then the information is NOT COMPLETE'''

= Overview, Groups, Feeds, Data =

The CSPR contains three main components - repositories, groups and feeds.

* Repositories are a collection of groups, most likely a Geeklog site (or could be another application).
* Groups are collections of feeds, usually about a standard topic (eg. News, Alerts, etc).
* Feeds hold data, and are derived from the group, eg. a `Main Geeklog News Feed` and a `VVT News Feed` for the group News.

Groups and Feeds can either be private or public. Public groups and feeds allow anyone to subscribe to them. Private on the other hand forces subscribers to be approved for access to various feeds.
Anyone is able to subscribe to a repository, however depending on the type (Public or Private) a different thing happens.
Each subscription is based on the actual repository - a public subscription means that only public groups and feeds are able to be joined, while a private subscription allows both public and private feeds to which the subscription is allowed.

Private subscriptions are assigned security groups. A security group is a collection of feeds that members of the group have access to. Private subscriptions can be assigned more than one security group. This allows an administrator of the repository to break down access into smaller chunks, and if a pay-subscription was wanted by the repository, it could offer different packages which then would match up to security group configurations.

The CSPR is modified through two interfaces. There is a GUI for the server and for the client (publishing and receiving respectively) which allow all basic tasks to be performed, eg. approving subscriptions, assigning security groups, creating groups and feeds, etc. The only thing the GUI does not support is adding data to a feed. The API on the other hand allow total manipulation of every aspect of the CSPR functionality. As well, the API allows plugins to hook into some of the GUI parts (subscribing, joining feeds) so the plugin does not have to recreate the wheel every time, however if the plugin developers so want to, it is easy to do.

= Plugins and using the API =

NOTE: @Result, directions for including lib files if not integrated into geeklog

Using the API differs depending on what side of the exchange you are developing for. For example, there are the PublishingControlManagement classes and methods that deal with repository or server end of things, and the ReceivingControlManagement classes and methods that deal with the joining/client end of things.

All data (Group, Feed, Subscriber, and Data information) are passed to and from methods using objects. These objects are GroupObject, FeedObject, DataObject, SecurityObject.

MAKE SURE TO READ THE DOCUMENTATION FOR EACH METHOD

Following is a list of classes for manipulating the basic structures for publishing

* Managing groups - PublishingGroupControl
* Managing feeds - PublishingFeedControl
* Managing data - PublishingDataControl
* Managing security and subscriptions - PublishingSecurityManagement
* Managing types - TypeObject

For receiving, there is only one class

* ReceivingControlManagement

Plugins are able to utilize the API and structure into their existing code in any way they want to allow communication across the internet.
Since most plugins will not need groups, there is a way to have one main group for the entire plugin, that is not visible to the administrators, and looks to be part of the plugin.
This feature is called `no display`.

If you decide that you only want one group for the plugin (so no display is for you), then in the plugin's auto install, create the group with the no display flag set to true as the parameter, and the name to be unique. To ensure the name is unique, it MUST have a `%` symbol (percent) in it somewhere. This is a reserved character that is only available for no display groups.
The format for a unique group name is:
<pre>`Plugin Full Name - plugin_dir_name - % - randomvalue`
eg. `Cross Site Publishing and Receiving - cspr - % - 0.30`.
</pre>

You can then always get the group id for this group by using the
<pre>
PublishingGroupControl::getIdForNDTitle($title)</pre>
method that matches the unique title against the database to retrieve the ID for the group.

Code Study - Autoinstall and creating a no display group
<pre>
$pgc = new PublishingGroupControl();
$groupObject = new GroupObject();

// Fill the group object
$groupObject->_Title = "Cross Site Alert Plugin - csa - % -100";
$groupObject->_Summary = "Cross site alert plugin only group";
$groupObject->_Type = TypeObject::O_PUBLIC; // Always make the no display group public

// Create the group
try {
$pgc->createGroup($groupObject, TRUE); // Create the group with no display on. Since no display is on, the % sign is OK. However if it was no a no display group, the % is reserved.
} catch(PublishingException $p) {
echo "HELP";
}

</pre>

The basis to any successful integration of the CSPR is understanding the two sections - the server or repository and the client. You may only want one or both of the sections depending on what your plugin is designed to do.
The actual data in a feed is bound to a unique Access Code that identifies the destination for the data. For example, the access code will determine what plugin or use the data is used for.
You can register a new access code at the main geeklog site for use with your plugin. You are also able to use an existing access code for your plugin if you want to use data intending for another use.

Cross Site Publishing and Receiving Information

2010-08-16T21:49:07Z

TimPatrick: /* Plugins and using the API */

= Introduction =

The Cross Site Publishing and Receiving API and GUI (Referred to as `CSPR` from here on) allows plugins to accomplish the following:

* Publish and receive any type of data among not only Geeklog sites but any application (web or desktop) that support the ATOM protocol and implement the REQUEST commands.

Using the CSPR is extremely easy, and all work can usually be done in a few API calls (for integrating support) or in a few clicks (using the GUI).

= Overview, Groups, Feeds, Data =

The CSPR contains three main components - repositories, groups and feeds.

* Repositories are a collection of groups, most likely a Geeklog site (or could be another application).
* Groups are collections of feeds, usually about a standard topic (eg. News, Alerts, etc).
* Feeds hold data, and are derived from the group, eg. a `Main Geeklog News Feed` and a `VVT News Feed` for the group News.

Groups and Feeds can either be private or public. Public groups and feeds allow anyone to subscribe to them. Private on the other hand forces subscribers to be approved for access to various feeds.
Anyone is able to subscribe to a repository, however depending on the type (Public or Private) a different thing happens.
Each subscription is based on the actual repository - a public subscription means that only public groups and feeds are able to be joined, while a private subscription allows both public and private feeds to which the subscription is allowed.

Private subscriptions are assigned security groups. A security group is a collection of feeds that members of the group have access to. Private subscriptions can be assigned more than one security group. This allows an administrator of the repository to break down access into smaller chunks, and if a pay-subscription was wanted by the repository, it could offer different packages which then would match up to security group configurations.

The CSPR is modified through two interfaces. There is a GUI for the server and for the client (publishing and receiving respectively) which allow all basic tasks to be performed, eg. approving subscriptions, assigning security groups, creating groups and feeds, etc. The only thing the GUI does not support is adding data to a feed. The API on the other hand allow total manipulation of every aspect of the CSPR functionality. As well, the API allows plugins to hook into some of the GUI parts (subscribing, joining feeds) so the plugin does not have to recreate the wheel every time, however if the plugin developers so want to, it is easy to do.

= Plugins and using the API =

NOTE: @Result, directions for including lib files if not integrated into geeklog

Using the API differs depending on what side of the exchange you are developing for. For example, there are the PublishingControlManagement classes and methods that deal with repository or server end of things, and the ReceivingControlManagement classes and methods that deal with the joining/client end of things.

All data (Group, Feed, Subscriber, and Data information) are passed to and from methods using objects. These objects are GroupObject, FeedObject, DataObject, SecurityObject.

MAKE SURE TO READ THE DOCUMENTATION FOR EACH METHOD

Following is a list of classes for manipulating the basic structures for publishing

* Managing groups - PublishingGroupControl
* Managing feeds - PublishingFeedControl
* Managing data - PublishingDataControl
* Managing security and subscriptions - PublishingSecurityManagement
* Managing types - TypeObject

For receiving, there is only one class

* ReceivingControlManagement

Plugins are able to utilize the API and structure into their existing code in any way they want to allow communication across the internet.
Since most plugins will not need groups, there is a way to have one main group for the entire plugin, that is not visible to the administrators, and looks to be part of the plugin.
This feature is called `no display`.

If you decide that you only want one group for the plugin (so no display is for you), then in the plugin's auto install, create the group with the no display flag set to true as the parameter, and the name to be unique. To ensure the name is unique, it MUST have a `%` symbol (percent) in it somewhere. This is a reserved character that is only available for no display groups.
The format for a unique group name is:
<pre>`Plugin Full Name - plugin_dir_name - % - randomvalue`
eg. `Cross Site Publishing and Receiving - cspr - % - 0.30`.
</pre>

You can then always get the group id for this group by using the
<pre>
PublishingGroupControl::getIdForNDTitle($title)</pre>
method that matches the unique title against the database to retrieve the ID for the group.

Code Study - Autoinstall and creating a no display group
<pre>
$pgc = new PublishingGroupControl();
$groupObject = new GroupObject();

// Fill the group object
$groupObject->_Title = "Cross Site Alert Plugin - csa - % -100";
$groupObject->_Summary = "Cross site alert plugin only group";
$groupObject->_Type = TypeObject::O_PUBLIC; // Always make the no display group public

// Create the group
try {
$pgc->createGroup($groupObject, TRUE); // Create the group with no display on. Since no display is on, the % sign is OK. However if it was no a no display group, the % is reserved.
} catch(PublishingException $p) {
echo "HELP";
}

</pre>

The basis to any successful integration of the CSPR is understanding the two sections - the server or repository and the client. You may only want one or both of the sections depending on what your plugin is designed to do.
The actual data in a feed is bound to a unique Access Code that identifies the destination for the data. For example, the access code will determine what plugin or use the data is used for.
You can register a new access code at the main geeklog site for use with your plugin. You are also able to use an existing access code for your plugin if you want to use data intending for another use.

Cross Site Publishing and Receiving Information

2010-08-16T21:44:35Z

TimPatrick: /* Plugins and using the API */

= Introduction =

The Cross Site Publishing and Receiving API and GUI (Referred to as `CSPR` from here on) allows plugins to accomplish the following:

* Publish and receive any type of data among not only Geeklog sites but any application (web or desktop) that support the ATOM protocol and implement the REQUEST commands.

Using the CSPR is extremely easy, and all work can usually be done in a few API calls (for integrating support) or in a few clicks (using the GUI).

= Overview, Groups, Feeds, Data =

The CSPR contains three main components - repositories, groups and feeds.

* Repositories are a collection of groups, most likely a Geeklog site (or could be another application).
* Groups are collections of feeds, usually about a standard topic (eg. News, Alerts, etc).
* Feeds hold data, and are derived from the group, eg. a `Main Geeklog News Feed` and a `VVT News Feed` for the group News.

Groups and Feeds can either be private or public. Public groups and feeds allow anyone to subscribe to them. Private on the other hand forces subscribers to be approved for access to various feeds.
Anyone is able to subscribe to a repository, however depending on the type (Public or Private) a different thing happens.
Each subscription is based on the actual repository - a public subscription means that only public groups and feeds are able to be joined, while a private subscription allows both public and private feeds to which the subscription is allowed.

Private subscriptions are assigned security groups. A security group is a collection of feeds that members of the group have access to. Private subscriptions can be assigned more than one security group. This allows an administrator of the repository to break down access into smaller chunks, and if a pay-subscription was wanted by the repository, it could offer different packages which then would match up to security group configurations.

The CSPR is modified through two interfaces. There is a GUI for the server and for the client (publishing and receiving respectively) which allow all basic tasks to be performed, eg. approving subscriptions, assigning security groups, creating groups and feeds, etc. The only thing the GUI does not support is adding data to a feed. The API on the other hand allow total manipulation of every aspect of the CSPR functionality. As well, the API allows plugins to hook into some of the GUI parts (subscribing, joining feeds) so the plugin does not have to recreate the wheel every time, however if the plugin developers so want to, it is easy to do.

= Plugins and using the API =

NOTE: @Result, directions for including lib files if not integrated into geeklog

Using the API differs depending on what side of the exchange you are developing for. For example, there are the PublishingControlManagement classes and methods that deal with repository or server end of things, and the ReceivingControlManagement classes and methods that deal with the joining/client end of things.

All data (Group, Feed, Subscriber, and Data information) are passed to and from methods using objects. These objects are GroupObject, FeedObject, DataObject, SecurityObject.

MAKE SURE TO READ THE DOCUMENTATION FOR EACH METHOD

Following is a list of classes for manipulating the basic structures for publishing

* Managing groups - PublishingGroupControl
* Managing feeds - PublishingFeedControl
* Managing data - PublishingDataControl
* Managing security and subscriptions - PublishingSecurityManagement
* Managing types - TypeObject

For receiving, there is only one class

* ReceivingControlManagement

Plugins are able to utilize the API and structure into their existing code in any way they want to allow communication across the internet.
Since most plugins will not need groups, there is a way to have one main group for the entire plugin, that is not visible to the administrators, and looks to be part of the plugin.
This feature is called `no display`.

If you decide that you only want one group for the plugin (so no display is for you), then in the plugin's auto install, create the group with the no display flag set to true as the parameter, and the name to be unique. To ensure the name is unique, it MUST have a `%` symbol (percent) in it somewhere. This is a reserved character that is only available for no display groups.
The format for a unique group name is:
<pre>`Plugin Full Name - plugin_dir_name - % - randomvalue`
eg. `Cross Site Publishing and Receiving - cspr - % - 0.30`.
</pre>

You can then always get the group id for this group by using the
<pre>
PublishingGroupControl::getIdForNDTitle($title)</pre>
method that matches the unique title against the database to retrieve the ID for the group.

Code Study - Autoinstall and creating a no display group
<pre>
$pgc = new PublishingGroupControl();
$groupObject = new GroupObject();

// Fill the group object
$groupObject->_Title = "Cross Site Alert Plugin - csa - % -100";
$groupObject->_Summary = "Cross site alert plugin only group";
$groupObject->_Type = TypeObject::O_PUBLIC; // Always make the no display group public

// Create the group
try {
$pgc->createGroup($groupObject, TRUE); // Create the group with no display on. Since no display is on, the % sign is OK. However if it was no a no display group, the % is reserved.
} catch(PublishingException $p) {
echo "HELP";
}

</pre>

The basis to any successful integration of the CSPR is understanding the two sections - the server or repository and the client. You may only want one or both of the sections depending on what your plugin is designed to do.
The actual data in a feed is bound to a unique Access Code that identifies the destination for the data. For example, the access code will determine what plugin or use the data is used for.

Cross Site Publishing and Receiving Information

2010-08-16T19:30:28Z

TimPatrick: /* Plugins and using the API */

= Introduction =

The Cross Site Publishing and Receiving API and GUI (Referred to as `CSPR` from here on) allows plugins to accomplish the following:

* Publish and receive any type of data among not only Geeklog sites but any application (web or desktop) that support the ATOM protocol and implement the REQUEST commands.

Using the CSPR is extremely easy, and all work can usually be done in a few API calls (for integrating support) or in a few clicks (using the GUI).

= Overview, Groups, Feeds, Data =

The CSPR contains three main components - repositories, groups and feeds.

* Repositories are a collection of groups, most likely a Geeklog site (or could be another application).
* Groups are collections of feeds, usually about a standard topic (eg. News, Alerts, etc).
* Feeds hold data, and are derived from the group, eg. a `Main Geeklog News Feed` and a `VVT News Feed` for the group News.

Groups and Feeds can either be private or public. Public groups and feeds allow anyone to subscribe to them. Private on the other hand forces subscribers to be approved for access to various feeds.
Anyone is able to subscribe to a repository, however depending on the type (Public or Private) a different thing happens.
Each subscription is based on the actual repository - a public subscription means that only public groups and feeds are able to be joined, while a private subscription allows both public and private feeds to which the subscription is allowed.

Private subscriptions are assigned security groups. A security group is a collection of feeds that members of the group have access to. Private subscriptions can be assigned more than one security group. This allows an administrator of the repository to break down access into smaller chunks, and if a pay-subscription was wanted by the repository, it could offer different packages which then would match up to security group configurations.

The CSPR is modified through two interfaces. There is a GUI for the server and for the client (publishing and receiving respectively) which allow all basic tasks to be performed, eg. approving subscriptions, assigning security groups, creating groups and feeds, etc. The only thing the GUI does not support is adding data to a feed. The API on the other hand allow total manipulation of every aspect of the CSPR functionality. As well, the API allows plugins to hook into some of the GUI parts (subscribing, joining feeds) so the plugin does not have to recreate the wheel every time, however if the plugin developers so want to, it is easy to do.

= Plugins and using the API =

NOTE: @Result, directions for including lib files if not integrated into geeklog

Using the API differs depending on what side of the exchange you are developing for. For example, there are the PublishingControlManagement classes and methods that deal with repository or server end of things, and the ReceivingControlManagement classes and methods that deal with the joining/client end of things.

All data (Group, Feed, Subscriber, and Data information) are passed to and from methods using objects. These objects are GroupObject, FeedObject, DataObject, SecurityObject.

MAKE SURE TO READ THE DOCUMENTATION FOR EACH METHOD

Following is a list of classes for manipulating the basic structures for publishing

* Managing groups - PublishingGroupControl
* Managing feeds - PublishingFeedControl
* Managing data - PublishingDataControl
* Managing security and subscriptions - PublishingSecurityManagement
* Managing types - TypeObject

For receiving, there is only one class

* ReceivingControlManagement

Plugins are able to utilize the API and structure into their existing code in any way they want to allow communication across the internet.
Since most plugins will not need groups, there is a way to have one main group for the entire plugin, that is not visible to the administrators, and looks to be part of the plugin.
This feature is called `no display`.

If you decide that you only want one group for the plugin (so no display is for you), then in the plugin's auto install, create the group with the no display flag set to true as the parameter, and the name to be unique. To ensure the name is unique, it MUST have a `%` symbol (percent) in it somewhere. This is a reserved character that is only available for no display groups.
The format for a unique group name is:
<pre>`Plugin Full Name - plugin_dir_name - % - randomvalue`
eg. `Cross Site Publishing and Receiving - cspr - % - 0.30`.
</pre>

You can then always get the group id for this group by using the
<pre>
PublishingGroupControl::getIdForNDTitle($title)</pre>
method that matches the unique title against the database to retrieve the ID for the group.

Code Study - Autoinstall and creating a no display group
<pre>
$pgc = new PublishingGroupControl();
$groupObject = new GroupObject();

// Fill the group object
$groupObject->_Title = "Cross Site Alert Plugin - csa - % -100";
$groupObject->_Summary = "Cross site alert plugin only group";
$groupObject->_Type = TypeObject::O_PUBLIC; // Always make the no display group public

// Create the group
try {
$pgc->createGroup($groupObject, TRUE); // Create the group with no display on. Since no display is on, the % sign is OK. However if it was no a no display group, the % is reserved.
} catch(PublishingException $p) {
echo "HELP";
}

</pre>

Cross Site Publishing and Receiving Information

2010-08-16T19:30:12Z

TimPatrick: /* Plugins and using the API */

= Introduction =

The Cross Site Publishing and Receiving API and GUI (Referred to as `CSPR` from here on) allows plugins to accomplish the following:

* Publish and receive any type of data among not only Geeklog sites but any application (web or desktop) that support the ATOM protocol and implement the REQUEST commands.

Using the CSPR is extremely easy, and all work can usually be done in a few API calls (for integrating support) or in a few clicks (using the GUI).

= Overview, Groups, Feeds, Data =

The CSPR contains three main components - repositories, groups and feeds.

* Repositories are a collection of groups, most likely a Geeklog site (or could be another application).
* Groups are collections of feeds, usually about a standard topic (eg. News, Alerts, etc).
* Feeds hold data, and are derived from the group, eg. a `Main Geeklog News Feed` and a `VVT News Feed` for the group News.

Groups and Feeds can either be private or public. Public groups and feeds allow anyone to subscribe to them. Private on the other hand forces subscribers to be approved for access to various feeds.
Anyone is able to subscribe to a repository, however depending on the type (Public or Private) a different thing happens.
Each subscription is based on the actual repository - a public subscription means that only public groups and feeds are able to be joined, while a private subscription allows both public and private feeds to which the subscription is allowed.

Private subscriptions are assigned security groups. A security group is a collection of feeds that members of the group have access to. Private subscriptions can be assigned more than one security group. This allows an administrator of the repository to break down access into smaller chunks, and if a pay-subscription was wanted by the repository, it could offer different packages which then would match up to security group configurations.

The CSPR is modified through two interfaces. There is a GUI for the server and for the client (publishing and receiving respectively) which allow all basic tasks to be performed, eg. approving subscriptions, assigning security groups, creating groups and feeds, etc. The only thing the GUI does not support is adding data to a feed. The API on the other hand allow total manipulation of every aspect of the CSPR functionality. As well, the API allows plugins to hook into some of the GUI parts (subscribing, joining feeds) so the plugin does not have to recreate the wheel every time, however if the plugin developers so want to, it is easy to do.

= Plugins and using the API =

NOTE: @Result, directions for including lib files if not integrated into geeklog

Using the API differs depending on what side of the exchange you are developing for. For example, there are the PublishingControlManagement classes and methods that deal with repository or server end of things, and the ReceivingControlManagement classes and methods that deal with the joining/client end of things.

All data (Group, Feed, Subscriber, and Data information) are passed to and from methods using objects. These objects are GroupObject, FeedObject, DataObject, SecurityObject.

MAKE SURE TO READ THE DOCUMENTATION FOR EACH METHOD

Following is a list of classes for manipulating the basic structures for publishing

* Managing groups - PublishingGroupControl
* Managing feeds - PublishingFeedControl
* Managing data - PublishingDataControl
* Managing security and subscriptions - PublishingSecurityManagement
* Managing types - TypeObject

For receiving, there is only one class
* ReceivingControlManagement

Plugins are able to utilize the API and structure into their existing code in any way they want to allow communication across the internet.
Since most plugins will not need groups, there is a way to have one main group for the entire plugin, that is not visible to the administrators, and looks to be part of the plugin.
This feature is called `no display`.

If you decide that you only want one group for the plugin (so no display is for you), then in the plugin's auto install, create the group with the no display flag set to true as the parameter, and the name to be unique. To ensure the name is unique, it MUST have a `%` symbol (percent) in it somewhere. This is a reserved character that is only available for no display groups.
The format for a unique group name is:
<pre>`Plugin Full Name - plugin_dir_name - % - randomvalue`
eg. `Cross Site Publishing and Receiving - cspr - % - 0.30`.
</pre>

You can then always get the group id for this group by using the
<pre>
PublishingGroupControl::getIdForNDTitle($title)</pre>
method that matches the unique title against the database to retrieve the ID for the group.

Code Study - Autoinstall and creating a no display group
<pre>
$pgc = new PublishingGroupControl();
$groupObject = new GroupObject();

// Fill the group object
$groupObject->_Title = "Cross Site Alert Plugin - csa - % -100";
$groupObject->_Summary = "Cross site alert plugin only group";
$groupObject->_Type = TypeObject::O_PUBLIC; // Always make the no display group public

// Create the group
try {
$pgc->createGroup($groupObject, TRUE); // Create the group with no display on. Since no display is on, the % sign is OK. However if it was no a no display group, the % is reserved.
} catch(PublishingException $p) {
echo "HELP";
}

</pre>

Cross Site Publishing and Receiving Information

2010-08-16T19:22:20Z

TimPatrick: /* Plugins and using the API */

= Introduction =

The Cross Site Publishing and Receiving API and GUI (Referred to as `CSPR` from here on) allows plugins to accomplish the following:

* Publish and receive any type of data among not only Geeklog sites but any application (web or desktop) that support the ATOM protocol and implement the REQUEST commands.

Using the CSPR is extremely easy, and all work can usually be done in a few API calls (for integrating support) or in a few clicks (using the GUI).

= Overview, Groups, Feeds, Data =

The CSPR contains three main components - repositories, groups and feeds.

* Repositories are a collection of groups, most likely a Geeklog site (or could be another application).
* Groups are collections of feeds, usually about a standard topic (eg. News, Alerts, etc).
* Feeds hold data, and are derived from the group, eg. a `Main Geeklog News Feed` and a `VVT News Feed` for the group News.

Groups and Feeds can either be private or public. Public groups and feeds allow anyone to subscribe to them. Private on the other hand forces subscribers to be approved for access to various feeds.
Anyone is able to subscribe to a repository, however depending on the type (Public or Private) a different thing happens.
Each subscription is based on the actual repository - a public subscription means that only public groups and feeds are able to be joined, while a private subscription allows both public and private feeds to which the subscription is allowed.

Private subscriptions are assigned security groups. A security group is a collection of feeds that members of the group have access to. Private subscriptions can be assigned more than one security group. This allows an administrator of the repository to break down access into smaller chunks, and if a pay-subscription was wanted by the repository, it could offer different packages which then would match up to security group configurations.

The CSPR is modified through two interfaces. There is a GUI for the server and for the client (publishing and receiving respectively) which allow all basic tasks to be performed, eg. approving subscriptions, assigning security groups, creating groups and feeds, etc. The only thing the GUI does not support is adding data to a feed. The API on the other hand allow total manipulation of every aspect of the CSPR functionality. As well, the API allows plugins to hook into some of the GUI parts (subscribing, joining feeds) so the plugin does not have to recreate the wheel every time, however if the plugin developers so want to, it is easy to do.

= Plugins and using the API =

NOTE: @Result, directions for including lib files if not integrated into geeklog

Using the API differs depending on what side of the exchange you are developing for. For example, there are the PublishingControlManagement classes and methods that deal with repository or server end of things, and the ReceivingControlManagement classes and methods that deal with the joining/client end of things.

All data (Group, Feed, Subscriber, and Data information) are passed to and from methods using objects. These objects are GroupObject, FeedObject, DataObject, SecurityObject.

MAKE SURE TO READ THE DOCUMENTATION FOR EACH METHOD

Following is a list of classes for manipulating the basic structures for publishing

* Managing groups - PublishingGroupControl
* Managing feeds - PublishingFeedControl
* Managing data - PublishingDataControl
* Managing security and subscriptions - PublishingSecurityManagement
* Managing types - TypeObject

Plugins are able to utilize the API and structure into their existing code in any way they want to allow communication across the internet.
Since most plugins will not need groups, there is a way to have one main group for the entire plugin, that is not visible to the administrators, and looks to be part of the plugin.
This feature is called `no display`.

If you decide that you only want one group for the plugin (so no display is for you), then in the plugin's auto install, create the group with the no display flag set to true as the parameter, and the name to be unique. To ensure the name is unique, it MUST have a `%` symbol (percent) in it somewhere. This is a reserved character that is only available for no display groups.
The format for a unique group name is:
<pre>`Plugin Full Name - plugin_dir_name - % - randomvalue`
eg. `Cross Site Publishing and Receiving - cspr - % - 0.30`.
</pre>

You can then always get the group id for this group by using the
<pre>
PublishingGroupControl::getIdForNDTitle($title)</pre>
method that matches the unique title against the database to retrieve the ID for the group.

Code Study - Autoinstall and creating a no display group
<pre>
$pgc = new PublishingGroupControl();
$groupObject = new GroupObject();

// Fill the group object
$groupObject->_Title = "Cross Site Alert Plugin - csa - % -100";
$groupObject->_Summary = "Cross site alert plugin only group";
$groupObject->_Type = TypeObject::O_PUBLIC; // Always make the no display group public

// Create the group
try {
$pgc->createGroup($groupObject, TRUE); // Create the group with no display on. Since no display is on, the % sign is OK. However if it was no a no display group, the % is reserved.
} catch(PublishingException $p) {
echo "HELP";
}

</pre>

Cross Site Publishing and Receiving Information

2010-08-16T19:18:09Z

TimPatrick: /* Plugins and using the API */

= Introduction =

The Cross Site Publishing and Receiving API and GUI (Referred to as `CSPR` from here on) allows plugins to accomplish the following:

* Publish and receive any type of data among not only Geeklog sites but any application (web or desktop) that support the ATOM protocol and implement the REQUEST commands.

Using the CSPR is extremely easy, and all work can usually be done in a few API calls (for integrating support) or in a few clicks (using the GUI).

= Overview, Groups, Feeds, Data =

The CSPR contains three main components - repositories, groups and feeds.

* Repositories are a collection of groups, most likely a Geeklog site (or could be another application).
* Groups are collections of feeds, usually about a standard topic (eg. News, Alerts, etc).
* Feeds hold data, and are derived from the group, eg. a `Main Geeklog News Feed` and a `VVT News Feed` for the group News.

Groups and Feeds can either be private or public. Public groups and feeds allow anyone to subscribe to them. Private on the other hand forces subscribers to be approved for access to various feeds.
Anyone is able to subscribe to a repository, however depending on the type (Public or Private) a different thing happens.
Each subscription is based on the actual repository - a public subscription means that only public groups and feeds are able to be joined, while a private subscription allows both public and private feeds to which the subscription is allowed.

Private subscriptions are assigned security groups. A security group is a collection of feeds that members of the group have access to. Private subscriptions can be assigned more than one security group. This allows an administrator of the repository to break down access into smaller chunks, and if a pay-subscription was wanted by the repository, it could offer different packages which then would match up to security group configurations.

The CSPR is modified through two interfaces. There is a GUI for the server and for the client (publishing and receiving respectively) which allow all basic tasks to be performed, eg. approving subscriptions, assigning security groups, creating groups and feeds, etc. The only thing the GUI does not support is adding data to a feed. The API on the other hand allow total manipulation of every aspect of the CSPR functionality. As well, the API allows plugins to hook into some of the GUI parts (subscribing, joining feeds) so the plugin does not have to recreate the wheel every time, however if the plugin developers so want to, it is easy to do.

= Plugins and using the API =

NOTE: @Result, directions for including lib files if not integrated into geeklog

Using the API differs depending on what side of the exchange you are developing for. For example, there are the PublishingControlManagement classes and methods that deal with repository or server end of things, and the ReceivingControlManagement classes and methods that deal with the joining/client end of things.

All data (Group, Feed, Subscriber, and Data information) are passed to and from methods using objects. These objects are GroupObject, FeedObject, DataObject, SecurityObject.

Plugins are able to utilize the API and structure into their existing code in any way they want to allow communication across the internet.
Since most plugins will not need groups, there is a way to have one main group for the entire plugin, that is not visible to the administrators, and looks to be part of the plugin.
This feature is called `no display`.

If you decide that you only want one group for the plugin (so no display is for you), then in the plugin's auto install, create the group with the no display flag set to true as the parameter, and the name to be unique. To ensure the name is unique, it MUST have a `%` symbol (percent) in it somewhere. This is a reserved character that is only available for no display groups.
The format for a unique group name is:
<pre>`Plugin Full Name - plugin_dir_name - % - randomvalue`
eg. `Cross Site Publishing and Receiving - cspr - % - 0.30`.
</pre>

You can then always get the group id for this group by using the
<pre>
PublishingGroupControl::getIdForNDTitle($title)</pre>
method that matches the unique title against the database to retrieve the ID for the group.

Code Study - Autoinstall and creating a no display group
<pre>
$pgc = new PublishingGroupControl();
$groupObject = new GroupObject();

// Fill the group object
$groupObject->_Title = "Cross Site Alert Plugin - csa - % -100";
$groupObject->_Summary = "Cross site alert plugin only group";
$groupObject->_Type = TypeObject::O_PUBLIC; // Always make the no display group public

// Create the group
try {
$pgc->createGroup($groupObject, TRUE); // Create the group with no display on. Since no display is on, the % sign is OK. However if it was no a no display group, the % is reserved.
} catch(PublishingException $p) {
echo "HELP";
}

</pre>

A case study that will help understand how to create a plugin that uses these features is the cross site alert plugin, that allows sites to create alerts and share them.

Cross Site Publishing and Receiving Information

2010-08-16T19:12:11Z

TimPatrick: /* Plugins and using the API */

= Introduction =

The Cross Site Publishing and Receiving API and GUI (Referred to as `CSPR` from here on) allows plugins to accomplish the following:

* Publish and receive any type of data among not only Geeklog sites but any application (web or desktop) that support the ATOM protocol and implement the REQUEST commands.

Using the CSPR is extremely easy, and all work can usually be done in a few API calls (for integrating support) or in a few clicks (using the GUI).

= Overview, Groups, Feeds, Data =

The CSPR contains three main components - repositories, groups and feeds.

* Repositories are a collection of groups, most likely a Geeklog site (or could be another application).
* Groups are collections of feeds, usually about a standard topic (eg. News, Alerts, etc).
* Feeds hold data, and are derived from the group, eg. a `Main Geeklog News Feed` and a `VVT News Feed` for the group News.

Groups and Feeds can either be private or public. Public groups and feeds allow anyone to subscribe to them. Private on the other hand forces subscribers to be approved for access to various feeds.
Anyone is able to subscribe to a repository, however depending on the type (Public or Private) a different thing happens.
Each subscription is based on the actual repository - a public subscription means that only public groups and feeds are able to be joined, while a private subscription allows both public and private feeds to which the subscription is allowed.

Private subscriptions are assigned security groups. A security group is a collection of feeds that members of the group have access to. Private subscriptions can be assigned more than one security group. This allows an administrator of the repository to break down access into smaller chunks, and if a pay-subscription was wanted by the repository, it could offer different packages which then would match up to security group configurations.

The CSPR is modified through two interfaces. There is a GUI for the server and for the client (publishing and receiving respectively) which allow all basic tasks to be performed, eg. approving subscriptions, assigning security groups, creating groups and feeds, etc. The only thing the GUI does not support is adding data to a feed. The API on the other hand allow total manipulation of every aspect of the CSPR functionality. As well, the API allows plugins to hook into some of the GUI parts (subscribing, joining feeds) so the plugin does not have to recreate the wheel every time, however if the plugin developers so want to, it is easy to do.

= Plugins and using the API =

NOTE: @Result, directions for including lib files if not integrated into geeklog

Using the API differs depending on what side of the exchange you are developing for. For example, there are the PublishingControlManagement classes and methods that deal with repository or server end of things, and the ReceivingControlManagement classes and methods that deal with the joining/client end of things.

Plugins are able to utilize the API and structure into their existing code in any way they want to allow communication across the internet.
Since most plugins will not need groups, there is a way to have one main group for the entire plugin, that is not visible to the administrators, and looks to be part of the plugin.
This feature is called `no display`.

If you decide that you only want one group for the plugin (so no display is for you), then in the plugin's auto install, create the group with the no display flag set to true as the parameter, and the name to be unique. To ensure the name is unique, it MUST have a `%` symbol (percent) in it somewhere. This is a reserved character that is only available for no display groups.
The format for a unique group name is:
<pre>`Plugin Full Name - plugin_dir_name - % - randomvalue`
eg. `Cross Site Publishing and Receiving - cspr - % - 0.30`.
</pre>

You can then always get the group id for this group by using the
<pre>
PublishingGroupControl::getIdForNDTitle($title)</pre>
method that matches the unique title against the database to retrieve the ID for the group.

A case study that will help understand how to create a plugin that uses these features is the cross site alert plugin, that allows sites to create alerts and share them.

Cross Site Publishing and Receiving Information

2010-08-16T19:11:51Z

TimPatrick: /* Plugins and using the API */

= Introduction =

The Cross Site Publishing and Receiving API and GUI (Referred to as `CSPR` from here on) allows plugins to accomplish the following:

* Publish and receive any type of data among not only Geeklog sites but any application (web or desktop) that support the ATOM protocol and implement the REQUEST commands.

Using the CSPR is extremely easy, and all work can usually be done in a few API calls (for integrating support) or in a few clicks (using the GUI).

= Overview, Groups, Feeds, Data =

The CSPR contains three main components - repositories, groups and feeds.

* Repositories are a collection of groups, most likely a Geeklog site (or could be another application).
* Groups are collections of feeds, usually about a standard topic (eg. News, Alerts, etc).
* Feeds hold data, and are derived from the group, eg. a `Main Geeklog News Feed` and a `VVT News Feed` for the group News.

Groups and Feeds can either be private or public. Public groups and feeds allow anyone to subscribe to them. Private on the other hand forces subscribers to be approved for access to various feeds.
Anyone is able to subscribe to a repository, however depending on the type (Public or Private) a different thing happens.
Each subscription is based on the actual repository - a public subscription means that only public groups and feeds are able to be joined, while a private subscription allows both public and private feeds to which the subscription is allowed.

Private subscriptions are assigned security groups. A security group is a collection of feeds that members of the group have access to. Private subscriptions can be assigned more than one security group. This allows an administrator of the repository to break down access into smaller chunks, and if a pay-subscription was wanted by the repository, it could offer different packages which then would match up to security group configurations.

The CSPR is modified through two interfaces. There is a GUI for the server and for the client (publishing and receiving respectively) which allow all basic tasks to be performed, eg. approving subscriptions, assigning security groups, creating groups and feeds, etc. The only thing the GUI does not support is adding data to a feed. The API on the other hand allow total manipulation of every aspect of the CSPR functionality. As well, the API allows plugins to hook into some of the GUI parts (subscribing, joining feeds) so the plugin does not have to recreate the wheel every time, however if the plugin developers so want to, it is easy to do.

= Plugins and using the API =

NOTE: @Result, directions for including lib files if not integrated into geeklog

Using the API differs depending on what side of the exchange you are developing for. For example, there are the PublishingControlManagement classes and methods that deal with repository or server end of things, and the ReceivingControlManagement classes and methods that deal with the joining/client end of things.

Plugins are able to utilize the API and structure into their existing code in any way they want to allow communication across the internet.
Since most plugins will not need groups, there is a way to have one main group for the entire plugin, that is not visible to the administrators, and looks to be part of the plugin.
This feature is called `no display`.

If you decide that you only want one group for the plugin (so no display is for you), then in the plugin's auto install, create the group with the no display flag set to true as the parameter, and the name to be unique. To ensure the name is unique, it MUST have a `%` symbol (percent) in it somewhere. This is a reserved character that is only available for no display groups.
The format for a unique group name is:
<pre>`Plugin Full Name - plugin_dir_name - % - randomvalue`
eg. `Cross Site Publishing and Receiving - cspr - % - 0.30`.
</pre>

You can then always get the group id for this group by using the
<pre>
PublishingGroupControl::getIdForNDTitle</pre>
method that matches the unique title against the database to retrieve the ID for the group.

A case study that will help understand how to create a plugin that uses these features is the cross site alert plugin, that allows sites to create alerts and share them.

Cross Site Publishing and Receiving Information

2010-08-16T19:10:10Z

TimPatrick: /* Plugins and using the API */

Cross Site Publishing and Receiving Information

2010-08-16T18:13:05Z

TimPatrick: /* Plugins and using the API */

Cross Site Publishing and Receiving Information

2010-08-16T18:12:17Z

TimPatrick: /* Overview, Groups, Feeds, Data */

Cross Site Publishing and Receiving Information

2010-08-16T18:05:37Z

TimPatrick: /* Introduction */

Cross Site Publishing and Receiving Information

2010-08-16T18:03:15Z

TimPatrick: /* Overview, Groups, Feeds, Data */

Cross Site Publishing and Receiving Information

2010-08-16T18:00:49Z

TimPatrick: /* Overview, Groups, Feeds, Data */

Cross Site Publishing and Receiving Information

2010-08-16T17:54:36Z

TimPatrick: /* Introduction */

Cross Site Publishing and Receiving Information

2010-08-16T17:49:41Z

TimPatrick: New page: = Introduction = The Cross Site Publishing and Receiving API and GUI (Referred to as `CSPR` from here on) allows plugins to send and receive data

= Introduction =

The Cross Site Publishing and Receiving API and GUI (Referred to as `CSPR` from here on) allows plugins to send and receive data

Programmers/Developers Documentation

2010-08-16T16:22:24Z

TimPatrick:

Programmers/Developers Documentation

2010-08-16T16:22:11Z

TimPatrick:

Programmers/Developers Documentation

2010-08-16T16:05:53Z

TimPatrick:

Programmers/Developers Documentation

2009-08-09T21:29:19Z

TimPatrick:

Patches and Upgrades

2009-08-09T20:10:29Z

TimPatrick:

== Introduction ==

The repository allows a way to have patches or upgrades to existing plugins offered for one-click automatic installation via. the repository.
However, there is a certain file format that must be followed for patches and upgrades.

Since the act of patching and upgrading are almost the same (Both add/edit/remove files and / or SQL), the only difference is that an upgrade updates your plugin version number as well.
Hence the structure of both are identical.

In the root directory of the patch / upgrade, there has to be the following directories and files:

* admin - This folder holds the files that you would like to be moved to the public_html/admin/plugins/yourplugin folder. Files with the same name will overwrite existing ones.

* public_html - All files that you would like copied to /public_html/yourplugin folder.

* plugins - All files you would like to be copied to /plugins/yourplugin folder.

* updates.php -- See below for information on this file

== UPDATES.PHP ==

This file contains the instructions for the update / upgrade process to follow. This file is mandatory, and without it your patches / upgrades will not be able to be offered for automatic one-click install, instead will have to be manually installed by the user.

The structure of the file is as follows:

The file MUST include a static class named UpdatePlugin, that implements the PluginUpdateInterface interface.

PluginUpdateInterface interface:
<pre>
interface PluginUpdateInterface
{
public static function init();
}
</pre>

The sample class is below, with explanations:
<pre>
class UpdatePlugin implements PluginUpdateInterface
{
public static $_SQL_DATA = array();
public static $_SQL_PTABLES = array();
public static $PLUGIN_NAME = 'repositorylisting';

public static function init()
{
// do nothing
return true;
}

}
</pre>

* <tt>public static $_SQL_DATA</tt> - This is an array of SQL files, that is any SQL you would like to be executed as part of the update / upgrade.

* <tt>public static $_SQL_PTABLES </tt>- This is an array of all tables that your plugin currently has assigned to it in the Geeklog database. This is for backup purposes, as all plugin data is backed up before an update / upgrade, in case of corruption to avoid data loss.

* <tt>public static $PLUGIN_NAME</tt>- This is the name of the plugin that it goes by in the plugin table.

* <tt>public static boolean function init();</tt> This function must return either true or false. False indicates a serious error occurred and the update must be terminated. This function allows you to include any code you want to execute during the update / upgrade. UpdatePlugin::init() is called after everything has been performed (SQL and file moves), before cleanup happens.
This cannot be stressed enough - you MUST return TRUE or the installation of your update / upgrade will be terminated, and the changes rolled back. Hence do NOT return false for some tiny warning, unless it is serious enough to cancel installation. In this regard, this function is really only for adding new configuration values, removing old ones, and so on. This is not for any SQL or FILE MOVE operations - allow the built in functions do that work more efficiently and with corruption protection.

== How it works ==

Once an upgrade or a patch has been uploaded into the repository, if it is a patch, it is assigned a unique patch id for that plugin. If it is an upgrade, all it needs is the old version it is replacing. This is important. While patches can be made to work with any Plugin version, Upgrades will ONLY upgrade from the 'old plugin version' specified on upgrade upload. This is a security feature to prevent security holes where code is thought to be there, however since it is an old version, the code is missing and the plugin crashes or has vulnerabilities. With patches, this is not so much an issue, as upgrades will always include any fixes that have been issued as patches.

Once the client clicks 'Check for Updates', a check is performed against every repository in their repository database, and any updates / upgrades are returned. The user may then select which ones they wish to install, and they will install / or fail without affecting any other updates.

[[Category:Plugin Development]]

Patches and Upgrades

2009-08-09T20:08:07Z

TimPatrick:

== Introduction ==

The repository allows a way to have patches or upgrades to existing plugins offered for one-click automatic installation via. the repository.
However, there is a certain file format that must be followed for patches and upgrades.

Since the act of patching and upgrading are almost the same (Both add/edit/remove files and / or SQL), the only difference is that an upgrade updates your plugin version number as well.
Hence the structure of both are identical.

In the root directory of the patch / upgrade, there has to be the following directories and files:

* admin - This folder holds the files that you would like to be moved to the public_html/admin/plugins/yourplugin folder. Files with the same name will overwrite existing ones.

* public_html - All files that you would like copied to /public_html/yourplugin folder.

* plugins - All files you would like to be copied to /plugins/yourplugin folder.

* updates.php -- See below for information on this file

== UPDATES.PHP ==

This file contains the instructions for the update / upgrade process to follow. This file is mandatory, and without it your patches / upgrades will not be able to be offered for automatic one-click install, instead will have to be manually installed by the user.

The structure of the file is as follows:

The file MUST include a static class named UpdatePlugin, that implements the PluginUpdateInterface interface.

PluginUpdateInterface interface:
<pre>
interface PluginUpdateInterface
{
public static function init();
}
</pre>

The sample class is below, with explanations:
<pre>
class UpdatePlugin implements PluginUpdateInterface
{
public static $_SQL_DATA = array();
public static $_SQL_PTABLES = array();
public static $PLUGIN_NAME = 'repositorylisting';

public static function init()
{
// do nothing
return true;
}

}
</pre>

* <tt>public static $_SQL_DATA</tt> - This is an array of SQL files, that is any SQL you would like to be executed as part of the update / upgrade.

* <tt>public static $_SQL_PTABLES </tt>- This is an array of all tables that your plugin currently has assigned to it in the Geeklog database. This is for backup purposes, as all plugin data is backed up before an update / upgrade, in case of corruption to avoid data loss.

* <tt>public static $PLUGIN_NAME</tt>- This is the name of the plugin that it goes by in the plugin table.

* <tt>public static boolean function init();</tt> This function must return either true or false. False indicates a serious error occurred and the update must be terminated. This function allows you to include any code you want to execute during the update / upgrade. UpdatePlugin::init() is called after everything has been performed (SQL and file moves), before cleanup happens.

== How it works ==

Once an upgrade or a patch has been uploaded into the repository, if it is a patch, it is assigned a unique patch id for that plugin. If it is an upgrade, all it needs is the old version it is replacing. This is important. While patches can be made to work with any Plugin version, Upgrades will ONLY upgrade from the 'old plugin version' specified on upgrade upload. This is a security feature to prevent security holes where code is thought to be there, however since it is an old version, the code is missing and the plugin crashes or has vulnerabilities. With patches, this is not so much an issue, as upgrades will always include any fixes that have been issued as patches.

Once the client clicks 'Check for Updates', a check is performed against every repository in their repository database, and any updates / upgrades are returned. The user may then select which ones they wish to install, and they will install / or fail without affecting any other updates.

[[Category:Plugin Development]]

Patches and Upgrades

2009-08-09T18:23:17Z

TimPatrick:

Patches and Upgrades

2009-08-09T18:22:30Z

TimPatrick:

Patches and Upgrades

2009-08-09T18:17:10Z

TimPatrick: New page: == Introduction == The repository allows a way to have patches or upgrades to existing plugins offered for one-click automatic installation via. the repository. However, there is a certai...

Developing Plugins

2009-08-09T17:53:14Z

TimPatrick:

== Introduction ==

To allow your plugin to be automatically installed by a user from the repository, you must develop it (or convert it) to use the autoinstall.php method of installation.

You must follow the Directory Layout for your plugin as outlined here [[Suggested_and_Required_Directory_Layout_and_Files]].

As well, there are four files that must be included in the root directory of your plugin archive. These files are:

autoinstall.php [[Plugin_Autoinstall]]

autouninstall.php [[Plugin_Auto-Uninstall]]

functions.inc [[Functions.inc_-_Listing_of_the_Plugin_Functions]]

install_defaults.php [[Install_Defaults]]

== Uploading ==

If your plugin includes these files, then it will be offered for auto install via the repository (and download and manual install if the user so wishes).

However, if any of these files are missing, a warning will be shown and the plugin will ONLY be offered for manual download.
This can be fixed at any time, however, by simply editing your plugin in the repository, and uploading your fixed archive.
Supported archives to the repository are .tar.gz, .tar, .tar.bz2, and .zip.
Once you upload a plugin, it will be displayed when you go to the Repository Manager, and you will be able to edit it, upload patches for it, and upload upgrades for it, as well as remove it.

Developing Plugins

2009-08-09T17:49:50Z

TimPatrick:

Developing Plugins

2009-08-09T17:49:14Z

TimPatrick:

Developing Plugins

2009-08-09T17:48:10Z

TimPatrick: New page: == Introduction == To allow your plugin to be automatically installed by a user from the repository, you must develop it (or convert it) to use the autoinstall.php method of installation....

Programmers/Developers Documentation

2009-08-09T17:43:26Z

TimPatrick:

Structure and Information

2009-08-09T17:42:40Z

TimPatrick:

== Introduction ==

The repository allows a plugin to be automatically installed by the end user with a single click, receive updates and upgrades that can be installed with the click of a mouse!
However, to allow for single click installs, a few things must be done to your Plugins, Patches, and Upgrades.

For more information on patches and upgrades see:
*[[ Patches and Upgrades ]]

Structure and Information

2009-08-09T17:40:16Z

TimPatrick: New page: == Introduction == The repository allows a plugin to be automatically installed by the end user with a single click, receive updates and upgrades that can be installed with the click of a...

Programmers/Developers Documentation

2009-08-09T17:02:50Z

TimPatrick:

Programmers/Developers Documentation

2009-08-09T17:00:26Z

TimPatrick:

Programmers/Developers Documentation

2009-08-09T16:59:50Z

TimPatrick:

Programmers/Developers Documentation

2009-08-09T16:58:56Z

TimPatrick: