Evaluation help

[WillMorris]

I'm trying to see if PW is a good fit for our project. It looks like it is, but I'm not quite sure the best way to structure and build it out.

Looking for some input on best practices for setting up a system of sites in PW.

Right now, we have a main site with CMS-driven content here:

http://ebird.org/content/

The content follows this kind of structure:

Home

* News

** News Item 1

** News Item 2

** News Item 3

* About / Help

** Help Item 1

** Help Item 2

** Help Item 3

We also have sub-sites that are navigationally and structurally the same, but have different logos and sometimes different content.

Home

* News

** News Item 4

** News Item 5

** News Item 6

* About / Help

** Help Item 1

** Help Item 2

** Help Item 3

** Help Item 4

Example:

http://ebird.org/content/ak/

With our current CMS, when we create one of these new sub-sites, we copy the existing main site pages into a new folder, and the sub-site admins only have access to that folder.

For instance, only the AK admin only has access to the /ak folder.

The nice part about this setup is sub-site admins are free to add, edit, and delete pages as they see fit within their folder. They never see any of the other sub-sites or main site content.

The problem with this setup is most of the content stays the same between the main site and sub-site. It quickly gets out of sync, especially help/tutorial content that pertains to using the web app.

We want to see if we can set up Processwire to organize content with the following permissions:

Type 1

* Written by main-site staff

* Show on main-site only

Type 2

* Written by main-site staff

* Show on main-site and sub-site

* Not editable by sub-site

* Changes from main-site are reflected on sub-site

* Sub-site does not have the option to hide content (always appears)

Type 3

* Written by main-site staff

* Show on main-site and sub-site

* Not editable by sub-site

* Changes from main-site are reflected on sub-site

* Sub-site has the option to hide content

* When main-site creates content it is initially hidden on sub-site

Type 4

* Written by sub-site staff

* Show on sub-site only

What is the best way to structure this in PW?

Is this possible within the stock PW admin screens or will parts need to be done with our own custom screens accessing the PW API?

If so, how would you go about breaking it up?

Thanks.

[WillMorris]

I've worked through this a bit. The solution I have so far is to create wrapper page template to use within sub-sites.

The wrapper template has a page field that refers to the page on the main site containing the content that needs to be pulled in and kept synchronized.

The sub-site admins can then choose whether to show, hide, or reorder these wrapper-based pages.

This will work as long as the original page doesn't get deleted. If that happens, I need to figure out a way to find and delete all the wrapper templates using that page as well. It looks like it would be possible to do through the API, but not the stock admin tools.

Also, there's no way to automatically add new pages with this structure. Would also need to be a custom module, correct?

[Soma]

Hey, sorry that nobody seems to reply to this. Although it's quite long and difficult to grasp/understand. For me at least. It's always better to try keep it short and clear.

From your second post, I can say that it's easily possible to write a module with hooks for page actions like ::save/::delete etc and do something, according to what page is saved. For example write content to over pages in the tree. Or even copy the page to another location. There's quite a lot of functions/events that can be hooked via a module in PW. So it's relatively easy to sync pages, aslo because the API is so powerful and the tree based page structure makes it easy to depend it on certain setup.

Of course you could also create custom admin masks using API via bootstrap (including index.php) and access API using $wire->pages or wire("pages") namespace. PW is a great and easy framework to get done whatever you can imagine.

[WillMorris]

Thanks for the help. I realized after the fact that it was probably too broad. Just wasn't sure how to start breaking it down. I've had too many experiences in other systems where I spent time trying to do something and finally realized it wasn't possible without massive workarounds.

[Pete]

Just a quick one on custom modules - they were a bit off-putting to me at first, but if you're happy playing with the API then they're not too hard to create.

As is often the case, the best thing to do is have a look at some other modules already created - the default install has a helloworld.module in the site/modules but a glance at some of the slightly more complex ones should also give you some pointers. The good thing is that it's pretty easy to hook into most things which leaves the rest of the module down to your programming knowledge (or in my case taking a lead from some of the other modules to see how some things are done ).

[WillMorris]

Good to know about the module system. Still trying to get a feel for when to use the stock admin tools and when to create a custom module.

One problem I've encountered with other systems is when you rely on too many custom modules, upgrading becomes difficult, especially if the modules come from 3rd party sources.

[Pete]

Yep - that can often be a worry. The good thing about PW is that whatever hooks your module hooks into will still be here for the foreseeable future, as will the current API.

I'll leave it to ryan to confirm, but I don't see the current API calls ever changing to be honest (except in terms of new ones being added) as they're nicely abstracted from the functions themselves, so even if the core code for a $pages->find() call were to change (say something can be refined when PHP6 becomes the norm on webservers in a few years' time) then I still imagine the $pages->find() call in the API will be exactly the same even though the underlying code might get a tweak for performance purposes.

Similarly, the hooks that modules use are logically named enough that I can't see them changing either - at least the ones I've used so far.

It's this attention to detail - that I'll admit I've only just really thought of in this context - that makes PW considerably more future-proof than other CMS packages.

None of this guarantees that modules won't break with new upgrades, but I would say that for most basic module needs that simply use the API to perform certain functions that they would be pretty future-proof.

[ryan]

I'll leave it to ryan to confirm, but I don't see the current API calls ever changing to be honest

This is correct. My own sites depend on it.