This lesson describes important steps to take when planning your package. Specifically, we will discuss important considerations that it is helpful to prepare before creating the package, and we will discuss the difference between public and private packages - including how to control who has the ability to view and install your packages.
The first thing to consider before creating your package is what the exact purpose of the package will be and what should be included in it.
As a general rule of thumb, each package you create should have a single clear purpose and should only contain the assets strictly necessary to accomplish that purpose. It is often helpful to break more complicated parts of your site into smaller individual packages, which both makes them easier to maintain and to use on other sites.
One notable temptation when creating packages is to include demo content in the package. After all, who doesn't want to see how the package can be used right away? However, demo content can quickly bloat a site, may inadvertently end up being published to live sites, and may even cause sites to go over their quotas - particularly for free sites with their page limit. Instead, place your demo content and examples in the demo and documentation pages.
A second major consideration before creating your package is where you should build it. The source site for a package is permanent - once you create your package you will not be able to move it to a different source site.
When you create your package, you will have the opportunity to include a demo and a documentation page. These resources make your package much easier to understand and appreciate. Not all packages require a demo but every package can benefit from a documentation page.
It is relatively easy to create the demo and documentation pages after creating your package but there are a few benefits to creating them before creating your package. Here are some of the pros and cons:
Pros to creating the demo and documentation before creating the package:
Cons to creating the documentation before creating the package:
Regardless of whether you do it before or after creating your pacage, you should write documentation for all public packages. But do not actually include the demo and documentation pages as assets in the package - simply link to them from the package details.
It is important to think about who should have access to your package before you create it because once your packages is created you may be unable to change whether it is public or private.
Public packages may be viewed and installed by anyone with a Marketpath CMS account. This is great if you just want to make your work available for others to use. If you want to make your package public, however, you should be willing to put in a little extra effort to also make it usable and useful (for example: using best practices in your variable scoping and naming, writing clear and helpful documentation, etc...).
Public packages may be used in private pacakges but may not depend on other private packages. A public package may be changed to a private package if and only if it is not a dependency of any other public packages.
Private packages may only be viewed and installed by those with whom you share it, in addition to any site belonging to the same account as the source site.
Private packages may be used by other private packages but may NOT be used by any public packages. A private package may only be changed to a public package if it does not depend on any other private packages.
Packages may be shared with users, sites, accounts, or agencies. For each of these you have the option of sharing either indefinitely or until a predetermined expiration date. When sharing with users or agencies you have the additional ability to allow the user or agency to share your package with others using their package collections (more on that later).
You may also revoke access at any time to anyone that the package has been shared directly with.
Note that removing access for a user, site, account, or agency will not affect any sites that have already installed the package. Once a site installs a version of a package, they will continue to have permanent access to all version that they have already installed. In affect what this means is that those sites will be unable to install new versions of your package but may continue to use the versions that they had access to before their access was removed.
Sharing with
Users: Enter an email address to share the package with. The user with that email address will be able to install the package on any site that they have access to, although other administrators of that site may be unable to update the package to newer versions. If you allow the user to share your package with others then they can grant others access to your private package by placing it in a private collection which they curate and share.
Sites: Enter the connection code of a site in order to grant access to the package for a specific site. Any administrator of the site will be able to install or update the package on that site, but not necessarily on any other site.
Accounts: Enter the connection code of an account in order to grant access to the package for any site under an account. Any administrator of any site under thaat account will be able to install or udpate the package on those sites. This includes new sites that are created under that account.
Agencies: Enter the connection code of an agency in order to grant access to the package for all agency users. Any user in the agency will be able to install or update the package on any site that the agency has access to, although other administrators may be unable to update the package to newer versions. If you allow the agency to share your package with others then they can grant others access to your private package by placing it in a private collection which they curate and share.
Please fill out the form below with your feedback or any questions you may have after working through the "Planning" lesson.