Multiple sections: there’s no need to copy the snippet or code files. The logic stays the same, it’s just the parameters that change.
All you need to do is keep your sections under different parent resources, and create a separate post-editing and post-management resource for each. The snippet call in the editing page and Ditto calls in the others will have parameters to pick the data for the relevant section. That might include different tagging TVs, as well. You’ll also need separate config files for your previews. Make sure all the links in hidden form fields refer back to the right editing & management resources.
De-publication: there are a number of options here. Your choice will depend on factors such as how often you need to do this, who will be doing it, and how serious a risk it would be to have an unpublished item accidentally republished. Also whether you want the resource to be unpublished in MODx terms (Published flag cleared, not available on the web), or just hidden (have a private flag that prevents Ditto displaying it, but available publicly if someone knows the address - e.g. they bookmarked it).
Simple methods:
- Open the item for re-editing and hit the Preview button. This keeps it in view as a draft in the management screens with all other data intact, while clearing the Published flag.
- Set an end date that is in the past or a publication date in the future. This makes the item appear as Expired in the management screen, and makes it unpublished.
- Use the "Show in menu" field in the sample files and the Ditto
&showInMenuOnly parameter to control the listing. Item is still "published", it’s just not displayed in the listing.
Less simple:
- Create your own TV for hide/show item, add it to the edit-post form and check it in the main include file’s postback code. This needs to happen somewhere
after date comparisons and the check for Preview have adjusted the Published status, to override the status if required.
- Expand the above to allow for a new "action" parameter to be called from the post-management screen, adding a clickable "hide/show" field to the listing there. This would need to be handled along the same lines as the Delete action from there.
I have used the simple methods myself when I’ve needed to unpublish items, though it would be nice to do it thorugh a column in the management screen. I’m working on PubKit proper now, using PHP classes for custom features of different types of item, so may be able to program in a standard method for showing/hiding (avoiding direct manipulation of the Published field, because of the clash with dates and preview status). Hence I won’t be updating pkBlog for this.
Archive listing:
Reflect should the same for resources generated by pkBlog as it does for those created in other ways.
KP
☆ A M B ☆
