Where do you store global shared values?

[OLSA]

Hello for all.

What is your suggestion, or your practice to store global shared values (eg. contact details)?

Example (this small test website):

In footer you can see "summary" from "About us", and in right footer column "body" from "Contact" page (address), but also link to client Twitter and Facebook page. Also in top navigation you can find telephone number.

Problem is that what if client want to add and another telephone(s), or few new social links (Google Plus, Linkedin etc...), or second, third... office location etc.

There is many options:

1. hardcoding (eg. store some values in config.php)

Pros: fast rendering

Cons: all others

2. use independent fields + repeatable fields (eg. for social networks, or more office locations)

Pros: user friendly

Cons: more fields (database rows, resources)

3. use only few fields with special syntax and parsing (eg. textarea and in "one row one value", or any other values separator, or hanna code, shortcodes...)

Pros: fast to render, only one field for all values

Cons: not user friendly

4. build some "configuration" module with repeatable and sortable options (fields) and store values in JSON format

5. use native PW pages and later Page Select field

Cons: 10x slower than 3 (tested)

What is your suggestion or practice to get the best for users (admin) and for the system (PW resources, fast rendering...)?

Thanks,

Sasa

[mr-fan]

Some Additions.

5. using PageTable and pages for repeating items

    Pros: more userfriendly than repeaters and working with pages since everthing is a page

    Cons: no easy setup, more fields

6. using ProFields - Multiplier and Textareas

    Pros: less fields

    Cons: You have to buy ProFields

7. Combining ProFields with PageTable to have a Config Page for this kind of things...

    Pros: very userfriendly, less fields

    Cons: You have to buy ProFields

....at least some address fields, or footerlinks don't challenge your resources to much i think...so it's your choice on the best usability i think!

regards mr-fan

[Adam Kiss]

Additional fields on root page seem to be the most favourite option.

What those fields are in terms of Inputfield types, that's going to be your decision, based on your client (and his technical capabilities).

Also, relatively clean solution would be a repeater with two fields: 'type' (FieldtypeOptions) and 'value' (FieldtypeTextarea).

Quite simple to parse, just one field in admin, you can sort it/order it, etc.

[LostKobrakai]

I don't get some of the criterias you have on those methods. Why is speed a criteria for such rarely changing information as footer texts. Just cache it for like 24h and the speed of any used method is a non-issue. Also additional database tables (fields) are not really an issue, as it's mostly few additional bytes just like if you'd store the information in a file. The difficult parts (which really draw resources) that databases have to handle are other things.

With that in mind i'd go for additional fields of method 2. either on the homepage on a dedicated settings page. 

[OLSA]

Thank you all for fast answers!

I don't get some of the criterias you have on those methods. Why is speed a criteria for such rarely changing information as footer texts. Just cache it for like 24h and the speed of any used method is a non-issue. Also additional database tables (fields) are not really an issue, as it's mostly few additional bytes just like if you'd store the information in a file. The difficult parts (which really draw resources) that databases have to handle are other things.

With that in mind i'd go for additional fields of method 2. either on the homepage on a dedicated settings page. 

LostKobrakai thank you for answer and sorry because I didn't write here all "things", and this is only small part of all my "problems" with PW.

I am with ProcessWire last few months and I am trying to find best concept (and some "standardisation") for settings and configuration: "widgets"/"blocks" (managments, rendering options...), category list settings (layout, show/hide...), most visited and downloads hits (cache... (or externall services)) etc, etc...

As example, in one project has ~40 templates and >50 fields (with many settings options (fields and pages)) and because of that resources and speed are very important for me. Also want to use same concept on small and big projects (for global values).

Thanks.

[mr-fan]

~40 templates and >50 fields

Always depending on the project/strucure/needs but this sounds very much...i'm just building a huge website and stay with ~15 templates and about 30 fields...with many PageTable templates as partial blocks, seo fields, advanced kind of blog with settings and additonal stuff like "see_also" Pagefields and so on, own contact form, some widgets....

You should think about reusing fields in context of a template and may using URL segments to get less single templates.

For example on a blog i usually don't need extra templates for things like  /my-blog/archive/ or /my-blog/tagoverview/ - this all happens in one template using URL Segments...

Or is this a whole Webapp with some special kind of content, user interaction, intranet or something else?

regards mr-fan