Base Content type

[Zenophebe]

Hi, complete newbie to ProcessWire, and it's eerily similar to something I was working on for myself. However, there's one striking difference which I'd like to suggest for processwire.

Not all content can be represented nicely as a 'page', so I was hoping it'd be possible to have a base content type with some set functionality, and each content type inherit from this class. Therefore a page would inherit from it, and then add all the relevant page methods and members, and each content type can be used to populate pages.

E.g. each uncached page would initiate a db request for data, and that data is populated into separate vars, for example: $page->body->author->name

$page->body->product->title

$page->body->article->body

etc.

Having separate content types would allow logical grouping of fields, and also of managing data. This could be stored nicely in the database because each content type could have its own table, and fields be added as necessary.

From what I can see so far, it looks like processwire already separates the fields of the page, so although I haven't looked at the code too much, it shouldn't be too much to use a base Content class?

[Philipp]

Don't call it pages, call it content type.

While ProcessWire is using the name or label "Pages", it can be basically everything. A user is a page, the whole admin area consist just of pages and you could create your own content types. What you mentioned is basically there. Use templates for your content types, link them with the Page (PageSelect) field and then you can cross-access values in the tempalte files.

Quick Example:

Create a template for product, add the needed fields.

Create "Products" by creating new pages with that template.

Now create a field with of the "Page" type and call it product. This allows you to link pages. Set it to "Single item" and add it to your desired "Page"-Template.

Now you can select your product on the other "Page" and access it via API with $page->product->title

[Zenophebe]

Exactly, 'page' is the base content type - it shouldn't be. there should be several base content types, and then in the admin, it can be, "add new skyscraper", "add new architect" etc. A template shouldn't be used as the glue to glue the fields together, that doesn't create a type, it just creates a group of fields. The concepts of a skyscraper or an architect are non-existant when using pw!

And using "Page" as the base type is just confusing as anything! It should require minimal changes surely? Each content type can have one or a set of templates, so the creation of an item should be similar?

[Joss]

A page isn't anything - it does not exist.

It is only the result of a template - and you can create as many templates as you want.

And templates only have to have associated files with them if the resultant pages are being rendered - because you can pull the contents of fields into any template from any other page created with any other template.

So, a page is not a base content type at all - there is NO base content type, you have to create them.

For more on pages see this old thing:

https://processwire.com/talk/topic/2296-confused-by-pages/

[Martijn Geerts]

I don't know what you mean by content type. But if that means Content-Type like in MIME or something the world would go open for you

You can add whatever header() you wish to a template and serve the page as if it was something else. 

A page can be everything. It can be a PDF or an MP3 or a JSON object or GIF what ever you set in the headers.

[Zenophebe]

i was thinking more like drupal approaches content types, but of course, not as bad as drupal. content types as being types of content, not as in file types.

[Joss]

I think you are misunderstanding how ProcessWire works.

The reason Drupal has content types is because they welded a CCK on top of the system as an after thought.

ProcessWire has no such restrictions. You create dedicated templates for everything. You want a review page? You create a template for it. You want an event page? Create a different template - and so on and so forth.

In fact, you HAVE to do that - the blank install has nothing in it. It is a blank sheet of paper for you to play with.

Systems like Joomla and Wordpress are not really Content Management Systems - they are Article Management Systems which have to be bent to work with different types of content.

ProcessWire is a true content management system in that is manages any kind of content that you want to create. 

Pages, as I said before, are whatever you want them to be. They are not a limited thing like the mainstream Drumlapress. They are just what you create from whatever template you design.

[Zenophebe]

Well, as I understand it, I think you're misunderstanding what a content type is. From what I can see, ProcessWire doesn't have the concept of content types, only pages that show certain fields. This isn't welding fields together to create a content type, it's just creating a huge mish mash of data that only exists as a 'content type' at view time. Making pages children of another page called, say 'products' doesn't create a product data / content type.

[kongondo]

i was thinking more like drupal approaches content types, but of course, not as bad as drupal. content types as being types of content, not as in file types.

Unless you can point to some agreed/standard web terminology, content type seems mainly to be a Drupal concept (OK, so there's also SharePoint but that's another story). It's just one way of organising and 'naming' content. MODx has resources, Drupal has nodes/content types (of which a 'basic page' is but one type), here we mainly organise our content using 'pages'. There's no right or wrong way....that's just the way it is. But we do like our 'pages'

[Mike Rockett]

@Zenophebe

This isn't welding fields together to create a content type, it's just creating a huge mish mash of data that only exists as a 'content type' at view time.

You can call it a 'mish mash', if you like, but that's not what it is.

Let's be plain about this, and compare to a CMS like Bolt, which I use for some projects. Where you have your content-type definition in Bolt (which is defined in a YML file), you declare all the fields and options for that content-type. In PW, the same can be said of templates, only it's much easier to accomplish, and has support for an infinite hierarchy. So, templates are your content-type definitions, and Pages can be based on any of these templates, and can be put anywhere you like. What makes this not a 'mish mash', as that it allows you huge flexibility.

Making pages children of another page called, say 'products' doesn't create a product data / content type.

I don't think I fully understand this... Why would creating a child page create a content type?

If you create a 'products' template (that lists child products), you can then set rules (Family tab) on it that only allow the creation of pages based on the single 'single_product' template as children - this creates your 'product data'.

Once again, I draw back to flexibility. PW doesn't force anything on you. You need to fully grasp the concept of how PW works before you can fully understand, and make good use of, it's flexibility. From a CMS point-of-view, it allows you to do almost anything.

[teppo]

@Zenophebe: what we have now in ProcessWire and how it's flexible and all has been explained in this thread over and over again. Hope I'm not confusing this any more than is necessary, but I'd really like to hear a bit more about some of your points:

Not all content can be represented nicely as a 'page', so I was hoping it'd be possible to have a base content type with some set functionality, and each content type inherit from this class.

From what I can see, ProcessWire doesn't have the concept of content types, only pages that show certain fields.

What is it exactly that you mean by content type here, and how does it differ from what Templates and Pages currently provide? Could you name a solid example of a thing that "can't be represented as a page"?

Please don't get stuck on the naming -- Page is just a name for a content item in ProcessWire (imagine that we're talking about nodes, articles, resources, or whatever makes you happy) and Template is just the metadata that defines what kind of content it holds, and so on. Names have absolutely nothing to do with what these items of content are capable of doing.

The examples in your first post ($page->body->author->name etc.) are what one would in ProcessWire, typically, achieve through page relations. In this case I'm having hard time understanding what exactly "body" is though -- is it a field or is body supposed to represent a section of page with content of it's own? Is it just a deeper hierarchy that you're looking for?

Another way to achieve similar structure would be by using a fieldtype with more complex content structure. Table field (not to be confused with PageTable, though that's another option) would be an example of this, though perhaps not quite what you're thinking of yet; you can quite easily create fieldtypes with their own specific schema, and Table is a fieldtype that pretty much does this for you, allowing you to define the schema via backend GUI.

Overall I think it'd be much easier for us to understand your point, if you explained what the actual problem / difference is, instead of simply stating that "this doesn't exist" or "this can't be done with Pages". The thing is that we can keep arguing about whether pages can represent different content types for all week, but it's not going to get us anywhere unless we're on the same page about what it means first.

Also, if it's something that can be easily achieved using tools we have now, I'd suggest that you consider alternatives -- there's always more than one way to do things. ProcessWire is very flexible, and one can achieve just about any structure using it, but sometimes you will have to let go of your "one true way to do this" approach and consider using what the system provides.

If you're confident in your programming skills, you might also consider building a proof of concept. If that's the case, I'd probably start by taking a look at the Page.php (this is the Page we're talking about here) and WireData.php (the base data container in ProcessWire, which Page.php also extends). A lot of what ProcessWire currently does is based on the idea that "almost everything is a Page", so you'll probably have to do quite a bit of work to get around this, but there are other content types already (such as comments), and it's absolutely doable.

If you do build such a proof of concept, please let me know -- always interested in seeing new ways to do things, as long as they provide some sort of real benefit

[pwired]

The concept behind processwire:

http://en.wikipedia.org/wiki/ProcessWire
https://processwire.com/api/concept/
http://www.flamingruby.com/blog/anatomy-of-fields-in-processwire/

[Martijn Geerts]

A page that identifies it self as an image. There's no browser in the world that thinks this is a page.

A template is a Page factory, what you produce in that factory is up-to-you. Don't be fooled by the word Page as others allready mentioned. 

[PHPSpert]

Just had the problem where I wanted all templates to be served as JSON. This is what I did:

/wire/config.php

$config->prependTemplateFile = '_init.php';

site/templates/_init.php:

<?php
header("Content-Type: application/json; charset=utf-8");
?>

and it worked fine.

Now if you wanted to, you could simply create a field in Processwire for each page that allows for a custom setting, like:

<?php
header("Content-Type: " . $page->custom_content_type . "; charset=utf-8");
?>

in your appended file.

Works like a charm.

[teppo]

/wire/config.php

$config->prependTemplateFile = '_init.php';

Otherwise this looks like a valid solution, but editing *anything* in the /wire/ directory is a bad idea. For config settings, see /site/config.php. If the setting you're trying to edit only exists in /wire/config.php, copy it to /site/config.php and it'll work just fine.

[Pierre-Luc]

ProcessWire is mostly a model with handy functions attached to them. You provide the views and the controllers. Simple as that. You can do what the heck you want with it. If you want to make a page have multiple possible states, suit yourself, it's possible.

That being said I think we're being trolled and falling pretty hard for it.

[adrianmak]

Don't limit your thought by the name 'Page'.

[Mike Rockett]

Indeed - this stumped me when I started with PW last year, but quickly caught on. I like to think of them as entities, nodes, or objects.