Hi WEC Team

Is there a way to get WEC config running also for subdomains in a single Tree installation?
Have you already started to develop this feature or do we need to start developing an own extension based on WEC config?

It would be good if WEC Config would work with the page Tree OR if all ROOT-Domain Records are Listed in WEC Config and you can choose from one to do the specific settings (Second way wuld be the one we would prefer as it is much more userfriendly only to see the ROOTdomain Records.

The idea is to check for all templates which have the rootflag set and then list them in WEC-Config! We are also thinking about changing to tabs instead of a dropdown, as we have to add some more "tabs" for specific datainput which should be the same in each church or subchurch.

Hope Churches have lots of churches worldwide and dito international fellowship groups. All churches will be placed in a singletree installation, but each church should be able to configure their own CONFIG Part - beside the MAJOR Configure Part (Only accessible for the MAINWEBADMIN) we also have to integrate like the cooluri URLManager and a "Click TS/Conf Installer sheet where people can choose their specific installation from a list.

A similar sheet will then also exist for each churchWEC config where the churches can i.e. choose from different menulayouts ...

The idea behind this is to get some kind of configuration part working for the people instead of writing the TS Codes by themselfs they can simply click or choose (radiobutton (OR)) and then the specific TS/Conf Part will be read from the TS STO folder into the specific roottemplate (Similar like we do it in traditional TYPO3 Teplates if you run a professional business. You have small snippets and you can even reuse all of them or export/import t3d them. Beside a TV-Template Repository also a TS Repository could be buld up for our church members.

Would be nice to get some input, so we don't invent wheels twice ;-)

Thanks

Andi

It can be done:
http://www.parkstreetbrethren.com and http://www.luminusnetwork.com are all in one page tree. Granted, they even use different Domains, but you can have the subdomains point the same way.

BUT:
If you are going to have a LARGE number of pages/subsites, I would recommend you dont share a page tree. If one issue happens, you are in ALOT of trouble, and with page caching and the sheer volume of the site, it could crawl like a snail. I understand the desire to share resources, but be wary of the other issues that may result. If you have any questions, drop me one on my site.

Stephen Knowlton
Red Red Design Typo3 AfterCare

Andi,

Okay, let's say 50 churches are all in one TYPO3 install.

We have thousands of pages and 15 or so domains on our church website and size does not seem to be an issue. Even with many more websites, TYPO3 may be fine.

I wonder most about managing all that.

- You could not give them access to the Admin account because then one person everyone up.

- You'd need to create powerful backend user accounts (but not admin), but there are still a lot of things they could not do like installing extensions.

- You would need to do the system management for all the churches.

- As time progresses, different churches may want different extensions and some extensions may even conflict with each other.

- Upgrades would require all churches to coordinate and be prepared to upgrade at one time. We have had extension upgrades that required changes to every place it is used. So that could get harder with 50 websites.

- Clearing cache may be an issue. There is an extension that allows you to let non-admin backend users clear cache but then they would clear cache for all websites. This is very inefficient.

- Any sort of global feature would need to be the same on all sites (like settings in the install tool).

I could be wrong, but my general feeling is that a single install approach would result in some challenging management issues before the size and loading issues would become an issue. I bet there is lots more challenges too if we thought about it some more.

My gut feeling is that you would be better off with a shared source via symlinks, but with separate installs for each church. Then they could each have their own admin account and they could make changes as they choose. They would be pretty independent. Of course, with this approach, upgrading becomes more work because you need to upgrade each site. But it still seems better for management and for the end users.

Does anyone else have any suggestions here?

In Christ,
Mark

Oh Mark Sorry

Probably my question was posed wrong. Yes of course we don't want to run every church in one Tree but we run Churches at one Place and their subchurche as well as their Ministries and subdomains on one Tree.

i.e

Hope of Phuket International Church is also the head of all PangNga Hope Churches. OurPastor is the Head Pastor of different churches too! Also we have sub ministries in each subchurch.

My question was according the WEC_CONFIG extension!

It works at the moment only for ONE Domain and it would be really good if this EXTENSION would work also for subdomains. Otherwise those subparts need either an own side - what would be really stupid as they are a Part of our church OR we could have only ONE BASIC-ADMIN in the MAIN-CHURCH instead of having a BASIC-ADMIN per Ministry and Subchurch what would be better.

Globe
- MainChurch Site
------- Subchurch
------- Subchurch
-------------Ministry with own subdomain
------- Subchurch
-------------Ministry with own subdomain

A Youth Ministry probabbly would like other Templates like a Senior Ministry. They need other Constants and so on.

It is ONLY the TOOL WEC_CONFIG I am talking here!

Meanwhile the process for those subministries is i.e. to always have to set the constants in a very complicated way thru the TYPOScript editor and then people need rights for it they should not have, as they can access also parts they should be accessible - like the general PAGE setup

It is only the TOOL the nice Button under WEB you can push and the a window pops up. You choose the Templaterecord from a Pagetree (This could be restricted i.e. for a Youth Ministry - they would only see THEIR Youth Ministry Tree Part!)
Now they can ddo all changes like we all do aleady on the MainTemplate using WEC Config instead of clicking thru to the WEC_constants and again to the TemplaVoila Templates and so on.

This Tool should work for all ROOT Pages in a Page Tree!!!

The upgrading is not such a big Problem Mark. Our settings might look a bit strange but they work out perfectly and we host lots of sites with ONE Main TYPO3, ONE Place for all General Template WEC,ABC those for all users, and ONE IMAGE Repository which is already indexed in DAM in all installations and so on.

To Achieve this you only would need to separate the SYSTEM PART from the INDIVIDUAL Part. like it is already done in TYPO3 if you download the dummy Package and install the System Package NOT inside the dummy Package. You only need to change 2 symlinks.
One to the T3-SYSTEM and ONE inside Fileadmin to the general RESOURCE-CENTER.
Works perfectly.
Have a look (Sorry its in German as I wrote it for the German Mailinglist)



Setting up a WEC Site like this would it make possible for any Church / Institutio to run multiinstallations/domains easily

You only would need to provide three files:

1. The TYPO3BASE T3SYSTEM Folder with its subsystem
2. The CUSTOMERFILES CUSTOMER1 (WEC without T3System but already inked to the right places
3. The "HOSTING" Part what I called like this
It holds everything what should be available for all customers i.e. the TV-Templates

We are setting up ourT3Pack like this!

Andi

Andi,

Your shared source approach looks good and makes sense. That is what I was hoping you would do. :-) Sorry I misunderstood.

For multiple domains within one church, who would create the template records with the root option set? If those root pages are not in the root of the page tree then it will also probably require changes to the template Typoscript. It seems like that process may require even more skills and if they have those skills then perhaps it would not be so hard for them to set WEC Constants with the constants editor, and set the structure and template fields in the page record of the root page.

In Him,
Mark

Hi Mark

The complete Churchwebsite structure including all its subroots will be set up by a MASTER-ADMIN. He will have access to everything (and actually don't need the WEC - even it is more comfortable for him too :-)

All subparts with ROOT - i.e. Ministrie Root, subchurch Roots and so on will have their own webadmins.

They have normally no big knowledge. They like to use the WEC-CONFIG Part - especially the way how to choose and change a template and do also those other settings like contact, copyright, ...

If you would send them into the template section they would mess up a lot!

So it is just the other way round like you wrote above.

For a MultidomainSetting we actually need THREE functions

SYSTEM-ADMIN (in our case that is myself who sets up the complete system and has access to everything in the system, extensions and so on)

MASTER-ADMIN (he is the one - like our TODAY Basicadmin) He would be able to set GENERAL SETTINGS like CoolUri/RealURL Base Records - System related things)

BASIC-ADMIN (new) (he is only responsible for ONE Subroot. He should be able to change templates, change several constants and so on.

Another point came up yesterday in a discussion here. As we are using Templates with much more funktions HOW can we ADD additional constants without disturbing the WEC-ORDER

1. We could create a NEW extension based on WEC and using the base Values + our Values
2. We get together and try to define the other - missing values - together with You and they will be added in WEC for future use.
3. We do it like Michael Cannonbose and work completely without WEC-Constants.

In my development for the new flexible Template I added the following functions.

Block A1-A4
div a1 - lib.day (TS to show Day and Time
div a2 - lib.login (login made like on TYPO3/Org small on top -
could be extended to an AJAX Popup
div a2 - lib.languageMenu (sr_languagemenue)
div a3 - lib.fontsizer (fontsizer-extension)
Block B1-B4
div b1 - lib.logo2 (aligned right)
div b2 - lib.logo (aligned left)
div b3 - lib.sitename
div.b4 - lib.siteslogan
Block C1-C4
div c1 - lib.icons
div c2 - lib.space (area between menu and icons)
div c3 - lib.fix (area on the right of horizontal Menu)
div c4 - lib.mainmenu
Block D1-D4
div d1 - lib.search
div d2 - lib.subtitle
div d3 - lib.pagetitle
div d4 - lib.breadcrumb
---
div un - lib.altmenu (vertical menu starting with level 1)
div uc - lib.rightcontent
---
div sb - lib.bannerimage
div sc - lib.leftcontent
---
div mc - lib.maincontent
---
div fa - lib.bottom (area for a generaldisplay on all pages at the bottom)
div fb - lib.statistic (area on all pages to display
i.e. site statistics lateron ajax foldup)
div fn - lib.bottonnav
div cr - lib.copyright
div cc - lib.contact
---
div f1 - lib.tip (Tip a Friend/Bookmark ...)
div f2 - lib.counter (website counter)
div f3 - lib.poweredby (Use of Package T3Pack)
div f4 - lib.lastup (Last Update)

----------------

The mainmenu starts like yours with "menulist"
the altmenu starts with "n2" - but perhaps "altlist" would be more logical.

----------------

As our goal with TPack is to build a complete Package with features people often need long time for to get them running, we integrated and try to integrate those lib.***s

They can be used of course also for other things. I first tried to name them more neutral but then it did not work anymore with the WEC Package. Especially as Our Templates all can FLIP to any position we don't really have left and right. So we took the naming conventon from Mollio which is Utility-column (uc) and Sidebar-Column (sc) and Main-Column (mc)

While the utility column holds the vertical menu and the sidebar two content areas. Here we have chosen your bannerimage element as you already use it in this column on several templates.

All Areas inside the mainArea will also be available as FCEs i.e. so you can insert FCEs with a menu into a singlecolumn page.

If you have some more naming conventions or conventions you probably will choose in future,then please drop us a note as our goal is to enhance WEC with our templates and not to create a separate package solution for all kind of Organisations and Schools - not only churches.
---------------

Please have a look also to the following discussion - sorry it is in German until now but perhaps somebody can help you with translating.

I dropped the idea in the German Mailinglist to create a Typoscript repository.
Elmar already registered anExtension Key tsrep and Sebastian opened up a wiki.

The idea behind all this is to develop a STANDARDISED TS-Repository. This has to follow exact guidelines like naming conventions even in TS in Extensions and also in CSS.

This way it would be possible to share code much easier and make it available for ALL INSIDE TYPO3.

I told them already that WEC is in my eyes the BIGGEST TYPO3 Community (and the only one too) which uses Standards to build templates, libs, mappings and so on.

Please try to catch up and join the discussion mainly:
Elmar Hinz, Joey Assenau, Matthias Stuebner, Sebastian Boettger, Georg Rehfeld and Myself. It wouldn't be good if beside the already working WEC-Standards new standards would be created.

http://lists.netfielders.de/pipermail/typo3-german/2007-June/034411.html
http://lists.netfielders.de/pipermail/typo3-german/2007-June/034362.html
http://lists.netfielders.de/pipermail/typo3-german/2007-June/034553.html

There is already a snippetbase existing HIDDEN inside TYPO3 ( we learned about this some days ago from Joey! It is made with wec_knowledgebase. Try to step in as the discussion is also about to use Knowledgebase or a WIKI.

Andi


Andi

Hi again

Here is the link to this HIDDEN typoscript Knowledgebase where we just heard about. It is very difficult to find that's why I call it hidden.
Here the link:

http://support.typo3.org:8080/jive/kbcategory.jspa?categoryID=1

Andi

Andi,

It seems that you are making a very nice specialized package to meet your needs. Perhaps we could incorporate some of your features, but it does not seem like what you are doing matches the needs for WEC. The WEC Starter Package needs to be as simple as possible because users have difficulty understanding all the options.

In Him,
Mark