Pages: Some changes I would like

[TDBF]

Hi,

Just started using Pages again and really like a lot of the changes from 3.4, however, there are some things I would like to see changed in the future.

1. Database Templates: Would it be possible that the templates could have their own folders or the ability to create folders? The way it stands at the moment I could see things getting messy pretty quickly. For example, all the default Listing, Form, Display, Category Index and Category Articles could go into a 'Default' templates folder? That way, storing and managing custom templates becomes a lot easier and a lot neater (The current method is playing havoc with my OCD )
2. Creating New Databases: Stop forcing us to tie a database with a template. Sometimes I will create a database to use with a custom field and will not be data that will be displayed directly via a template. Having to do this constantly every-time is time consuming and needles in many cases.

Thanks

[TAMAN]

1. You can create templates with the same group names

for example custom listing, display, Category list...etc templates under one group name

[TDBF]

18 minutes ago, TAMAN said:

1. You can create templates with the same group names

for example custom listing, display, Category list...etc templates under one group name

Yes, I know. but all the templates are just thrown into that group named folder regardless of their original category.

I would like to be able to create a folder called 'My Pages Templates' and copy Listing, Form and Display folders and their templates into there keeping their original folder structure. The way it is now, starts to get very messy rather quickly.

[TAMAN]

mmm in my opinion this is way cleaner for me, everything in one folder i would get really pissed off if it was folder in folders... 

[opentype]

2 hours ago, TDBF said:

 

1. Database Templates: Would it be possible that the templates could have their own folders or the ability to create folders?

I agree. It’s quite messy on all my sites in that section. 

2 hours ago, TDBF said:

1. Creating New Databases: Stop forcing us to tie a database with a template. Sometimes I will create a database to use with a custom field and will not be data that will be displayed directly via a template. Having to do this constantly every-time is time consuming and needles in many cases.

Having to do what exactly? I don’t follow. 

[TDBF]

15 minutes ago, opentype said:

Having to do what exactly? I don’t follow. 

When creating a field and choosing Database Relationship as the type. You cannot use a database unless it has a 'page' assigned to it. Even though the data in this database will not be made public, I am forced to add a page to it.

It also irks me a little that it is assumed that every database will automatically be used to display content. In IPB 3 Pages when you created a database, it never made you automatically choose a title and content field. The database, was in fact a blank slate and you could use this for data storage that could be accessed by fields in other databases or stored records that could be displayed in a table.

You cannot even remove the Title or Content fields from the database table, which in my opinion, is wrong. Why give you a powerful tool to create databases on the fly and make you use fields that you may not inherently want? Not every database you would want to create will be used will be to display Articles.

 

1 hour ago, TAMAN said:

mmm in my opinion this is way cleaner for me, everything in one folder i would get really pissed off if it was folder in folders... 

Fair enough, but should I be given the option to do what would increase my workflow? The way you work (No offense) would drive me up the wall in no time, being hit will a wall of templates in one folder without know which template belonged to Listings, Forms or Displays isn't my idea of fun.

[opentype]

7 minutes ago, TDBF said:

When creating a field and choosing Database Relationship as the type. You cannot use a database unless it has a 'page' assigned to it. Even though the data in this database will not be made public, I am forced to add a page to it.

I see. I get that, since I use Pages databases as non-public data storage option as well, but it just not intended to do that and also wasn’t in 3.4. The logic of the interface follows its intended use. And obviously, if you link a database as a stock option, it needs a page to link to – or the functionality would simply break at one place or another in the intended use. So they way it works makes perfect sense. 

7 minutes ago, TDBF said:

You cannot even remove the Title or Content fields from the database table, which in my opinion, is wrong. Why give you a powerful tool to create databases on the fly and make you use fields that you may not inherently want?

As I just said, it is not built as data storage option. It is built to display stuff to on a page – not necessarily articles, but having some kind of title and some kind of content for a record just makes sense in 99% of those normal cases. And they are simply needed/useful in the regular use. The title field is used for creating the default record URL or to find a record in the ACP. The body field is used for Open Graph content and the search function for example. So again, it’s done this way for a reason and IP.Content basically had the same functionality regarding the title and body field.  

 

[Meddysong]

42 minutes ago, TDBF said:

It also irks me a little that it is assumed that every database will automatically be used to display content. In IPB 3 Pages when you created a database, it never made you automatically choose a title and content field.

This has caught me out, too. One of my databases has a category which is for requesting a word to add to a pronunciation database. Just the title would be enough, rather than asking people to type the same thing into the title and the content.

It doesn't help either that for the other categories in the database, the content will be uploaded sound files (the pronunciations). I can't make people attach a sound file in the "requests" category, and I can't expect them to add text content for no reason in the "pronunciation recordings" categories either. So it seems I'm going to have to split across two separate databases, even though these are related uses.

[opentype]

3 minutes ago, Meddysong said:

This has caught me out, too. One of my databases has a category which is for requesting a word to add to a pronunciation database. Just the title would be enough, rather than asking people to type the same thing into the title and the content.

You don’t have to do that. Just don’t expose the content field to the users by deactivating their permission to see it. 

[Meddysong]

Hmm ...

That sounds like a good work-around. So ... it'll be a mandatory field but with a default value, and nobody but me will be able to see it. It looks like I've had a similar thought to you at some point because I can see that when I upload just a title the word "test" appears in the body. So all I need to do is keep what I've done but change permissions, hey? Think I'll have another look at this later

[Meddysong]

Bah, great minds thinking alike. It turned out I'd already had the same idea as you, Ralf! What confused me is that the content still appears in the display template, so I was still seeing "test" after submission. I'll dip into the template in a bit and see what I need to remove from it.

[bradl]

5 hours ago, Meddysong said:

I'll dip into the template in a bit and see what I need to remove from it.

I believe you can remove permission for anyone to view it, including yourself. If a field exists in the forest but there's nobody to view it, does it really exist  

[Meddysong]

7 hours ago, bradl said:

I believe you can remove permission for anyone to view it, including yourself. If a field exists in the forest but there's nobody to view it, does it really exist  

Not in the case of this one, though, because it's not only a field (which can be controlled with permissions) but also the content for the record. So this line in the record template

<section class="ipsType_richText ipsType_normal" data-controller='core.front.core.lightboxedImages'>{$record->_content|raw}</section>

calls it irrespective of permissions. And commenting it out will remove it

[TDBF]

On 29/10/2016 at 3:04 PM, opentype said:

I see. I get that, since I use Pages databases as non-public data storage option as well, but it just not intended to do that and also wasn’t in 3.4. The logic of the interface follows its intended use. And obviously, if you link a database as a stock option, it needs a page to link to – or the functionality would simply break at one place or another in the intended use. So they way it works makes perfect sense. 

As I just said, it is not built as data storage option. It is built to display stuff to on a page – not necessarily articles, but having some kind of title and some kind of content for a record just makes sense in 99% of those normal cases. And they are simply needed/useful in the regular use. The title field is used for creating the default record URL or to find a record in the ACP. The body field is used for Open Graph content and the search function for example. So again, it’s done this way for a reason and IP.Content basically had the same functionality regarding the title and body field.  

 

Sorry, I disagree with to regards of the Database. A database is a storage engine and nothing more and doesn't need to be specifically tied to a Page. If you go back and look at IPContent in version 3.14, you can create a database without using a title, content or any other field for that matter (Maybe you should go back and have a look ) and you can select which field you want to be your title or content field. This way allows you to have complete control over what you do with the fields you add in this table.

I want to be able to create a Database for use with a drop down menu with two fields (the ID and a Title as an associative array) to use in another form. Right now, when you create a database, it adds a whole lot of fields to me that are not required and this just bloats this database with useless information that is not required. It may make perfect sense to use, but I'm sorry, it doesn't for me. It just makes me have to do a whole lot more work that quite frankly isn't required.

Also, making me have to go in and uncheck permissions and add a page to a Database in these case is time consuming and unnecessary and starts to become an annoyance after a while. I was able to do this in IPContent with v3.14 and I would like to still have that functionality now. IPS in their wisdom tried to dumb this down so casual users wouldn't have such a steep learning curve.

If IPS wanted to make it easier for people, then they should have just copied the functionality of WordPress and stored everything into one database, then given everyone the ability to add new fields. Right now, they have taken away the power of this application that there was in 3.14 and this has broken the functionality for people like myself.

 

[opentype]

26 minutes ago, TDBF said:

If you go back and look at IPContent in version 3.14, you can create a database without using a title, content or any other field for that matter (Maybe you should go back and have a look )

No, thanks. I know very well how IP.Content and Pages work and what has changed. 

My point remains: Neither IP.Content, nor Pages were directly intended to be internal “storage engines” to be accessed through custom coding. Quite the contrary! They were intended for normal admins to easily create public lists of arbitrary content WITHOUT custom coding. Articles, soccer player databases, movie titles or whatever. The database functionality was NOT meant to create menus for examples. So I understand that you don’t like a change that creates more work for you in such a case, but we can’t really blame IPS for not better supporting a use that was never intended in the first place. That’s all I am saying. 

[TDBF]

Who said anything about custom coding?

I am talking about taking a 'Database Relationship Field' and selecting a Database (In the Field Settings) which was created via IP Pages. So yes, I am using this is the way that IPS intended. However, like any other program, application or whatever I have used or created for article management (And I have written more than I care to remember), you don't always use a database you create for directly displaying articles or categories.

For example: If I want to create a football league, you will have many database's for this:

1. Teams
2. Seasons
3. Competitions
4. Players
5. Positions
6. Venues

So out of these, I will want to create database tables to store 'Seasons' and 'Competitions' information, which I will add to Selection Box/Database relationship fields when a creating form for teams, and I will also want to use this information (as array's) elsewhere in in my templates. The databases will therefore be displayed indirectly within forms, but I will STILL have to tie them to a Template? Just one more step that doesn't need to be taken.  So according to you, I shouldn't do this because it wasn't built into the applications parameters by the developers?!

[opentype]

1 hour ago, TDBF said:

Who said anything about custom coding?

I can clearly infer that from what you are saying. ;-)  And you proved it in the same post. ☞ “use this information (as array's) elsewhere in in my templates”

 

Quote

I am talking about taking a 'Database Relationship Field' and selecting a Database (In the Field Settings) which was created via IP Pages. So yes, I am using this is the way that IPS intended.

No, you are not. The database relationship field is specifically made to LINK records. Not internally, but literally. To create an <a href… link to the “record” on the database page. And that’s why there always needs to be a page to link to as I explained before. It’s very simple and very clear. That’s what the stock template for that field does. And it does that, because that – and only that – is the primary or “intended” use. There is no way to deny that. 

 

Quote

So according to you, I shouldn't do this because it wasn't built into the applications parameters by the developers?!

You are free to do this and I perfectly understand what you are doing (since I set up several IPS sites just like that), but we are using the database feature in a way it was not directly meant to and therefore it might not be justified to complain about the fact, that the software doesn’t accommodate this “misuse” perfectly. 

But I am stopping now. We are already going in circles. I only joined to help you understand why things are the way they are. Feel free to consider it, ignore it, refute it … My point should be clear by now. I can’t do more. 

[TDBF]

OK, I'm glad that this application works for you out of the box and I hope it does for a long time. However, to me, I am asking that the developers could possibly change something's to make life easier for the likes of myself or other people who use this software.

Just because you believe that this is the way that this software should be used, you should not be close minded to the possibility that other could possible push the boundaries of how that software is used and improved on over an extended period of time, that is how software evolves over its lifetime.

6 minutes ago, opentype said:

No, you are not. The database relationship field is specifically made to LINK records. Not internally, but literally. To create an <a href… link to the “record” on the database page. And that’s why there always needs to be a page to link to as I explained before. It’s very simple and very clear. That’s what the stock template for that field does. And it does that, because that – and only that – is the primary or “intended” use.

Utter rubbish. With all due respect you are now coming across as condescending more than anything else rather than trying to help. As I said, I am glad that this software does what you want, but I will continue to ask for changes that will help make things a little easier for the likes of myself.

Regards,

[opentype]

Nothing of that represents what I said or meant or wanted in this discussion even remotely. Which is quite disappointing. But since I promised to stop, I won’t start quoting every sentence of that last post and set things straight. So I leave it at that and just generally point out, that the last post does not reflect my position.