Acibut JobGator

Introduction:
The goal of this project is to create a single WHMCS add-on and WPMU (MPMS) 3X Plug-in that, when combined, allow the for the purchase and automatic provisioning of WPMS accounts via WHMCS. There are plug-ins that do this currently, but none that address all features we require. The chosen developer will have access to these plug-ins if they donâ??t already, so that they can investigate how various tasks are carried out with these products.

During the purchasing process, username, password, domain name or sub-domain will be either selected by the new user or created based upon data entered. WHMCS account email address and WPMS email address will be the same for example, as will passwords. Passwords do NOT need to be kept in sync.

Project Guidelines & Requirements:
· Provisioning must be automatic, or compatible with WHMCS automatic provisioning options.
· Must support automatic upgrade/downgrade of accounts (which will impact other features such as storage, etc. â??see others below)
· Must be able to specify the amount of storage available to each site. This should be upgradable via WHMCS and be auto provisioned as well.
· Currently WPMS allows users to create an unlimited number of sites per account. This must be either:
Limited to one (1) site per account, or preferably
Limited to a specific number of sites per account level. i.e., bronze account = 2 sites, silver account = 4 sites, gold account = 8 sites, etc.
IMPORTANT: If the preferred method is possible, this must be configurable with each package within WHMCS and should also support the purchase of additional sites at any time.
Provisioning would still only create the one initial site. The admin on the account could manually create the others up to the number included with their account level or purchase post factum.
· Allow for the creation of â??setsâ?? of plug-ins and themes accessible to each account type. Note that the next account level would always include everything in the lesser account level.
IMPORTANT: When a Bronze account holder views plug-ins and themes, they should see all available options, but plug-ins or themes that require an upgrade should be locked and marked as such. â??Upgrade to Gold to access this feature.â?? or â??Upgrade to Silver to access this feature.â??
· Account names should not be hard coded, but definable by the plug-in user. This can be done within WHMCS or the WPMS plug-in. Either way.
· Atom Pub & XML-RPC should also be limited by account level.
· Must support automatic suspension of unpaid accounts, and automatic reactivation of accounts once balance is paid. This should be configurable using standard WHMCS options.
· Must support automatic account termination and deletion. This should be configurable using standard WHMCS options.

Other Considerations:

Structurally, this set of plug-ins and add-ons for WHMCS and WPMS should be build taking into consideration the desired impact of its use. We are looking for automation and cross capability, but weâ??re also looking for a good amount of flexibility and scalability. The number of themes and plug-in that will be used will grow and possibly change, likewise, some degree of â??On-Demandâ?? offerings must be possible. For example, while we need accounts to be provisioned automatically using a build in set of plug-ins and themes, we will likely find ourselves in a situation where weâ??ll need to add features to a specific account. Features like a custom theme, that we should be able to add to a single account without making it available to all other accounts on the WPMS network. The same will be true of plug-ins. In fact, in the future we may need the ability to make a theme or plug-in available to one account that has multiple sites, for which the addition should preferably (or optionally) be available all that account holderâ??s sites.

This package is on that will rely heavily on both platforms. The developer should have both a solid knowledge of both, but also be familiar with the â??directionâ?? of both projects, enabling him or her to make more informed choices about how this should come together in order to maximize future compatibility with upgrades and simplify future updates to maintain compatibility.

While weâ??re seeking a developer for a single project, it is our hope that we will be able to maintain a relationship with the chosen developer to facilitate maintenance updates and upgrades in the future. We understand, however that this may not be possible. As such, we will require not only all code associated with the project, but also light documentation explaining any unobvious programming, dependencies , etc.