Jump to content

Removing the title field? And proper use of pages?


Goca
 Share

Recommended Posts

Hi all!

I'm currently building a school quiz system in our site, and with back and forth interlinking, I'm finding that the Title field is not necessarily needed for some pages. The short of the design is...

  • The school is split into 5 modules
  • Each module has X number of quizzes
  • Each quiz has X number of questions

The only way I've thought to do this, with what little I know about ProcessWire so far, is entirely through the use of pages. So here is my current page structure:

Home
-- School
   -- Module 1
      -- Quiz 1
         -- Question 1
         -- Question 2
      -- Quiz X...
         -- Question X...
   -- Module X...

And so on.

The thing is, for questions, all I need is the Question Content, and some other minor metadata. There's no real "Title" to the question, as the question content itself is kinda both the content and title. Technically if the question is short enough, I could use the Title field for this joint purpose, but I can't guarantee the question won't exceed the 255 character format, plus the Title field feels like the wrong place for this data.

There's a more pertinent area where I don't need the title though, and that's in the other area of the site for Student Records:

Home
-- School
   ...
-- Student Records
   -- John Doe
      -- Module Record 1 (Relevant data being stored for a particular module as a whole)
         -- Quiz Response 1 (This record contains the student's answers for a particular quiz)
            -- Answer 1 (This record is a simple back and forth conversation between students and teachers)
            -- Response 1 (Response from a teacher if answer is incorrect)
            -- Answer 2
            -- Response 2
            -- Etc...
         -- Quiz Response X...
      -- Module Record X...
   -- Jane Doe
      ...

The main area of design that I'm not entirely sure of yet (because I'm still learning ProcessWire) is if I would be better off just using a repeater field for the Answer / Response records, and just making that a field for a Quiz Response instead of sub-pages, but I'm not certain how searchable Repeater data is, and the ability for teachers to very granularly search student / quiz data is important.

The basic linking of data is:

  • Modules are are defined within the "School" section of the site, Quizzes are assigned to a module as sub-pages, and Questions are assigned to a quiz as sub-pages.
  • Student Records are created for each student upon sign up with relevant data attached as fields (Name, Age, Email, other metadata, because I couldn't find a way to link fields to users instead of pages). Module records are assigned as sub-pages and contain data such as Module Progress, Current Quiz, etc. so teachers can track that data. Quiz Responses are assigned as sub-pages of Module Records, and linked to the relevant quiz by a Page Reference (mainly so that we can also view all answers for a particular quiz regardless of specified student). The answers / responses are then entered either as sub-pages, or repeater fields.

A lot of these pages do not particularly need their own titles because they can inherit titles from their linked pages with their Page Reference fields, however, I don't know how ProcessWire wants to handle all of this. Maybe the title is always required and should never be removed, and is okay to duplicate between pages even if it is always going to be the same (as in the instance of a Quiz, and a Quiz Response), but then I would also need to write routines so that if a Quiz title is ever updated, every Quiz Response title is also updated to match, which seems tedious when I can just link the 2 together and grab the Quiz title.

Or perhaps I'm going about this the wrong way, and I'd be better off using custom database tables? From everything I'm seeing, it seems like Pages can entirely be used for this purpose, even if 80% of them don't have template files because I will be aggregating and displaying the data via "Search" and "Dashboard" pages.

So I guess the overall question that I have is, if I disable the checkbox requiring Title on all pages, so that I can create some pages that don't have titles, is that dangerous?

Looking forward to any insight you all may have! ?

Link to comment
Share on other sites

  • Goca changed the title to Removing the title field? And proper use of pages?

Your question regarding titles is a common question, actually.

 

About your structure, I’m keen on advising against creating the questions as individual pages, I would rather you purchase ProFields and use a Table field instead - ProFields might even solve the problems you’ll have in the future. Not only will you have an ease in development, you’ll also support ProcessWire since this is an open source project and it relies on these paid modules for funding.

Link to comment
Share on other sites

I have a different opinion from @cryostar here. If you need this content to be easily searched, I would say it's better to keep the pages. As for the title, that link is a good read and there are other possible approaches, particularly with the use of hooks (don't have time to go through them now), but consider renaming the title field to "identifier" in those templates and leave it at that. This will greatly simplify your coding and will give editors a chance to add words that are not in the question but might be useful for searching later, it will also keep things tighter and more readable in the pages tree.

  • Like 1
Link to comment
Share on other sites

Hi @Goca and welcome to PW ? 

On 6/29/2021 at 11:34 PM, Goca said:

The main area of design that I'm not entirely sure of yet (because I'm still learning ProcessWire) is if I would be better off just using a repeater field for the Answer / Response records, and just making that a field for a Quiz Response instead of sub-pages, but I'm not certain how searchable Repeater data is, and the ability for teachers to very granularly search student / quiz data is important.

My learnings from 2018: Don't use Repeaters for such a use case!! ? 

On 6/29/2021 at 11:34 PM, Goca said:

From everything I'm seeing, it seems like Pages can entirely be used for this purpose, even if 80% of them don't have template files because I will be aggregating and displaying the data via "Search" and "Dashboard" pages.

Agreed. Pages are great! They are the most important part of PW, they are robust, versatile, scale well and everything will work with pages while not everything will work with repeaters or repeater matrix. Take RockMigrations or RockFinder or findRaw as examples...

On 6/29/2021 at 11:34 PM, Goca said:

So I guess the overall question that I have is, if I disable the checkbox requiring Title on all pages, so that I can create some pages that don't have titles, is that dangerous?

To be honest I don't know. But what I usually do is leave the title field there and use it for whatever I need (and I always need anything). That could be a unique ID of that page that could be used as some simple password protection or you could use it to concatenate data from two other fields or to create a better readable label that is simply shown in the page tree. You can simply set the field to locked or hidden and populate it via saveReady hook. Maybe 10 lines of code. No mess. No danger. And ideally some other benefits.

If you are building your own dashboards and lists I'd even consider structuring your page tree more like traditional database systems:

- schools
- modules
- quizes
- students

I can't prove that by good arguments now and I know too little about your exact system but for me putting too much business logic into the page tree did more harm than good.

Hope that helps a little ? You are already asking good questions ? 

  • Like 1
Link to comment
Share on other sites

4 hours ago, bernhard said:

My learnings from 2018: Don't use Repeaters for such a use case!!

So true! Repeaters are nice but... only in limited cases.

4 hours ago, bernhard said:

To be honest I don't know. But what I usually do is leave the title field there and use it for whatever I need (and I always need anything). That could be a unique ID of that page that could be used as some simple password protection or you could use it to concatenate data from two other fields or to create a better readable label that is simply shown in the page tree. You can simply set the field to locked or hidden and populate it via saveReady hook. Maybe 10 lines of code. No mess. No danger. And ideally some other benefits.

Keep the title field - reuse or overwrite it with a unique identifier of some kind or anything else... had so many cases I thought I wouldn't need it but at the end it was somehow my lifesaver or at least the one and only unique identifier I had.

Free your mind from the label "title"... you can write anything in it, either way. You could also ignore that field, remove it in your template to be seen and work with the module PageUseIdAsName to get your unique identifiers.

  • Like 1
Link to comment
Share on other sites

Yeah. The simplest solution I can think of would be to set visibility of the title field to "hidden (not shown in the editor)" --> setup > templates > yourtemplate > click on title field > visibility

Then just do whatever you want with that field via a simple hook. To test it place it in /site/ready.php - to get a good setup create an autoload module that handles your business logic and place the hook there.

<?php
// create a unique name on page creation (when id=0)
$wire->addHookAfter("Pages::saveReady(template=yourtemplate,id=0)", function(HookEvent $event) {
  // set unique name, see options array
  $page->name = $this->wire->pages->names()->uniqueRandomPageName();
});

// set title to full name (forename+surname) on every save (id>0)
$wire->addHookAfter("Pages::saveReady(template=yourtemplate,id>0)", function(HookEvent $event) {
  $page = $event->arguments(0);
  $page->title = $page->forename." ".$page->surname;
});

 

  • Like 1
Link to comment
Share on other sites

...just be aware that it might not be as simple as that. Those techniques will set the title on page creation. If the editor decides to modify those fields, the title won't be updated. You might have to account for that with a hook that listens to those fields being modified also. Conclusion: keep it simple if you can, and do these only if you absolutely think it's better not to have the title.

Edited by diogo
All wrong :D
Link to comment
Share on other sites

42 minutes ago, diogo said:

..just be aware that it might not be as simple as that. Those techniques will set the title on page creation. If the editor decides to modify those fields, the title won't be updated.

No - the name will be set ONCE on page creation. The title will be set on every save of the page.

Link to comment
Share on other sites

Thank you all for the insight! This has been super helpful.

This community continues to impress me with how helpful and kind everyone is. The more I learn about ProcessWire the more I like what I see!

This gives me the direction I need to continue development. I appreciate it!

  • Like 4
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...