Publishing concepts in ProcessWire

[wheelmaker24]

Hi there,

I started this topic to collect ideas about different publishing concepts in ProcessWire web pages that are used as big publishing systems. Please think of this topic as a collection of ideas and tools. So feel free to post your concepts as well.

When it comes to bigger publishing systems it is of course important to strike the balance between consistent page layouts and flexibility. Also it should be easy to handle for publishers (the frontend editing features could come in handy here).

Structures:

From my point of view there are different approaches. I think there is nothing like a "perfect solution", because decisions should be made from case to case.

1) Create one template per layout

This is of course the easiest way: A possible default page template would have fields for headers, main content, sidebar content and footers. For every other scenario you simply create a new page template. In the worst case you end up with thousands of different page layouts.

2) Use CKEdit or any other editor to handle layouts

Here your page content would basically consist of one field (e.g. body) and you let CKEdit handle everything else. As CKEdit is plugin based you could use something like the Bootstrap plugin to achieve different layouts on different pages. Although I have to admit that I'm not very comfortable with having a WYSIWYG editor handle the page layout.

3) Use page fields for content elements (PageTable or PageTableExtended)

For me this seems to be a good balance between flexibility and "controllable" layouts from a developer's perspective. Just create sub-templates for content blocks (e.g. content-table, content-gallery, content-infobox, ...) and make them available as child templates for every publishing page. Having a page field on the publishing template you can then add, edit and sort content parts.

Another way is to integrate content-templates via HannaCode (e.g. [[table]], [[gallery]], [[infobox]]...) and use it inside a CKEdit (this would pretty much be the WordPress approach).

The only thing not seeming "clean" to me is that is could be possible that content elements are page siblings to publishing pages (if you are not using one place for every content item to be saved in, which then could make permission management difficult).

4) Using GridManager

I've just come across this plugin which one can use as an InputType in the PW backend: Grid manager. This looks good for me but on the other hand could still be confusing for publishers that are only occasionally updating their content.

tbc...

[rick]

I think that each of your items all relate to usability. Regardless of the user type, whether they be a content writer or casual reader, the layout must remain consistent. By that I am referring to the following (as an example, not a complete list):

Menu(s): A user needs to be accustomed to accessing options in the same location, with the same visual queues (colors, icons, etc.), for all pages of a specific type.

Links: All links should be consistently displayed; underscores, background colors, whatever the desired style.

Images: The use of imagery is a bit more complex. For example, advertisements, figure references within articles, icons, etc., should all be consistently displayed. This requires a little bit more thought as to their creation and presentation.

Textual content: Again, consistency is the key. Refer to elements using the same format, such as a list of table data or a figure image. Table data is usually referred to by reference, while a figure is commonly referred to by illustration. Example: Figure 1. illustrates the ..., or, Refer to Table 1 for a list of ... . Even article elements such as a note to the reader should be consistent in it's content and appearance.

Basically, it comes down to this: A style guide should the standard for developing the site, just as a coding style guide is used in programming and a corporate standards manual is used with company creatives. The tools you as the developer provide to your users, ckeditor, page fields, etc., should be selected based on the best fit with the approved style guide.

Hope this helps!

[Martijn Geerts]

When it comes to bigger publishing systems it is of course important to strike the balance between consistent page layouts and flexibility. Also it should be easy to handle for publishers (the frontend editing features could come in handy here).

I would disagree on the last one. For bigger systems let the writers focus on the content not on the visual output. When you let them focus on desktop experience changes are they will write for desktop. In my opinion content should separated from view, articles should be device independent. For you as developer you have to give them the fields they have to fill in. This way you can get the content that is suitable for the platform where you wish to publish it.

In my opinion:

• A system should be a content management system (CMS), not web publishing tool per definition.
• The content should be written platform independent, (Not writing for a specific device).
  • Provide enough fields to pull from, when the need is there.
• The content should be modularity, so that it's it's easy to add different types of content.
  • Your example of page table would work.
• Insure your data is accessible and could be queried from other platforms (JSON API).
• Don't pollute your data with structural markup.
  • Don't use div's or image strings etc in you text directly. Use Page tables or something for images, video's etc.

[wheelmaker24]

Thanks for your responses, I totally agree with both of you!

I think the best solution is to define content elements (like tables, figures, attachments) that can be added to any page within a page field.

The problem we are facing is that we have to develop a structure that is working for 300+ sub pages. Of course we will develop according to a style guide which helps a lot in terms of how to display elements. But I wonder if it is possible by structural design to let publishers customize their pages without loosing consistency.

[Martijn Geerts]

I don't understand the 300 sub pages?

You mean, 10 posts a day 300 in a month ?

/posts/2015/12/19/postname/

/posts/2015/12/19/postnam2/

/posts/2015/12/19/postnam3/

/posts/2015/12/19/postnam4/

/posts/2015/12/19/postnam5/

/posts/2015/12/19/postnam6/

[wheelmaker24]

No, I meant 300+ "static" pages to be published within the website in total – counted without the news pages of course.

I am currently rethinking the intranet publishing pages for about 10.000 employees: The current system is based on company's standards (meaning SharePoint Server 2003…) and is of course getting a bit long in the tooth. The problem we are facing with the current system is that it is not very flexible. The life span of the new (ProcessWire) system should be at least as long as the life span of the current system – meaning it should be prepared for techniques coming in the next 10 years. Regarding the different pages published by over 50 editors, many of course want to achieve their "own" design. What I'm thinking of is how to balance options of making pages unique by their editors but still consistent within the whole system.

It is true what you say, that the system's editing options should not be based on the layout but on the content. But still: I don't want to restrict a system too much that should be flexible enough for the next 10 years ;-)

For example we've already created optional fields (restricted to a specific user role) to add additional head tags (like CSS links) or scripts just before the closing body tag. Using hanna code one is also able to implement jQuery plugins in the future without touching the template files (which in a production environment is not too easy anyway).

[rick]

No, I meant 300+ "static" pages to be published within the website in total – counted without the news pages of course.

... Regarding the different pages published by over 50 editors, many of course want to achieve their "own" design. What I'm thinking of is how to balance options of making pages unique by their editors but still consistent within the whole system. ...

What do these articles (written by the 50 or so authors) pertain to? Are they entirely individual points of view of various topics, or are they supposed to be related to some corporate business practice or general industry-field?

If an article is company-centric, then their 'own' design should be restricted to conform to the standards of the company. If the articles are not related to specific company practices or industry, then the author is less restricted. For example: A lawfirm would have articles (suits) that must adhere to specific standards of layout and content placement, etc., while also having articles (briefs) whose format and content are far less restricted. That same lawfirm may have established standards for each type of article (suits, briefs, etc.).