• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

Each user homepage should include a %MAINWEB%.UserHomepageHeader and show vital user info at the top so that other users can see the contact info "above the fold."

This is in preparation for TWiki:Codev.PurposeOfUserHomePage.

Here is the doc from TWiki:TWiki.UserHomepageSupplement:

This item introduces a UserHomepageHeader that can be shown at the top of every user homepage. The idea is to show useful information on the top, and that an administrator can change the header content for all users on a central location. Follow these steps to enable and customize the user homepage header:

-- PTh

What does this do that a VIEW_TEMPLATE doens't?

At TWiki:Codev.PurposeOfUserHomePage you talk about above and below the fold and the personal contact information being hidden. I though the VIEW_TEMPLATE brought the form to the top to address this?

On top of which, one of the main piees of contact information - the e-mail address - now seems to be filtered out.

All this seems inconsistent to me.

-- AJA

The FOLD. I wonder if you mean the form hidden by the twisty.

This feature has been removed again so the user form is now very visible.

On the email - if you use .htaccess type authentication like most Internet (not Intranet) sites do, the users have the right to not having their email addresses exposed to email harvesters. This is why it is not added per default.

The user can add it manually to the form if they wish to.

It is a pitty it has to be this way but we have to help people reducing the amount of spam they receive. The NOSPAM padding is useless today. It does not proetct anything. And now registration requires confirmation the user can not even use a bogus email address.

In the Corporate environment where you normally use a different authentication such as LDAP the email address is transferred to the form


"The fold" is the bottom browser window border. Most site designs still take a 800x600 browser window into account and place the most important stuff above the window border.


The user form has more information than the vital ones. So, I think it is more flexible to change the VIEW_TEMPLATE to show the form at the bottom, and to show only vital information (contact info and optional portal info) on top (above the fold, via include)

I did that at a client site and it is very flexible to use and customize.

So, for default install I suggest to:

  • Move the form to the bottom (default)
  • Create a %MAINWEB%.UserHomepageHeader that does a SEARCH on BASETOPIC to pull out vital contact info, and contains some help text on how to customize the header.
  • Update the NewUserTemplate to include the header

-- PTh


But: There is one issue left. The user form still shows up on top, not at the bottom. I changed end of UserViewTemplate to this:

%TMPL:P{context="inactive" then="inactive_form" else="active_form"}%

This should show the form at the bottom. Why is it shown on top?

-- PTh

Arthur refactored PatternSkin to have its own UserViewTemplate, called PatternSkinUserViewTemplate.

I like the new look of the user homepages with this one, thanks.


-- SP

SVN 9541 (TWiki4) and 9542 (Develop) create a better layout for the edit link, by placing it inside the form div.

  • Question: why is the e-mail the user has entered when registering not copied to the topic form?
  • E-mail and Email are both used on the same page. This should be made consistent to E-mail.
  • I wouldn't let a user change the form.
  • More discrepancies:
    • The view page has the user name spaced out, but the edit page shows the WikiWord name
    • The view page has the form field names spaced out ("First name"), but the edit page shows the WikiWord form names ("FirstName")
    • InstantMessaging is not spaced out
    • Why are these WikiWords at all? HomePage? Why not Homepage?


All of this discussion is important but... I thought 4.0.2 is for bug fixes only. Not changes to correct (perceived) misfeatures but actual bug fixes. Ipso facto, it does not belong in 4.0.2.

I was not at the ad hoc meeting wherein this was discussed, but I'm surprised (and disappointed) that there was a discussion at all about putting this into 4.0.2 beyond "it's not a bug fix". I took out at least one small, benign change without argument for that very reason.

There are still bugs and "misfeatures" that should be fixed post-haste. Nonetheless, the goal as of at least last week was to get 4.0.2 out as soon as possible and thus the remaining bugs and misfeatures should be deferred to either 4.0.3 or 4.1, depending on the time frame of 4.1. (See Item1901 and Item1966 for two examples that I posted.)


  • Question: why is the e-mail the user has entered when registering not copied to the topic form?
    • This was made as a deliberate change. Users are forced to give their valid email address now in order to register. So we have to respect not to make people email addresses visible. Not even with the very predictable and easy harvest NOSPAM padding known from Cairo. People can manually add their email if they want to expose it. This is key essential. I personally receive 50-100 spam mails per day and I know many that have felt forced to change email address to get off the spam lists. We have to respect that people do not want emails exposed. The way the registration is done now is that the email address is copied when the password manager is not apache. For example when you use an LDAP authentication instead.
  • E-mail and Email are both used on the same page. This should be made consistent to E-mail.
    • I remember that CC did not change this because it was connected to the actual code. If the email address is not hidden in a .htpasswd file it is derived from this field. So do not change the form. You will break the code .

And finally let me repeat that I personally do not like this change in the user home page. But maybe I am a minority here and then I have to accept that. But I do wonder why a decision and hard work was done to move the user form to the top and then in the last minute one person decides to put it back at the bottom.


This appears to have been reverted from TWikiRelease04x00 in SVN 9574, so unmarking "patch".


No, it is disabled, but patch still applies. See description at TWiki:TWiki.UserHomepageSupplement.

-- PTh

Now I'm really confused. I missed the meeting last night, but it said in the minutes that this was to be reverted. But it appears to be still there, but disabled? That rather defeats the whole point of reverting it, doesn't it. A patch is not supposed to ship any more code changes than are absolutely needed to fix bugs. Is it very high risk to revert it properly? Having the patch flag on this topic will result in it being included in the release notes; which is not what you intended, is it?


Nah, I find this hair splitting because:

  • There is no visual change
  • There is no code change, just small topic changes
  • There are other UI changes that are dramatic in comparison, such as Pattern skin layout changes with more customization options (very good changes BTW)
  • There are other doc changes that are more dramatic, such as TWiki variables change (a very good one BTW)
  • There are code changes that are more dramatic, such as...
    • Item1781 - Allow admin users to change passwords and mail addresses
    • Item1926 - Usability: Add tabindex + setfocus to template login form in PatternSkin
    • Item1960 - WebRss lacks search options
    • Item1963 - "public" in WEBLIST should include all webs if the user is an admin
    • Item1971 - Not possible to INCLUDE javascript from external sites
    • (all very good ones BTW)

Good try, but...

Now imagine how much more value I could bring to the TWiki community if:

  • my proposal would be discussed with an open mind, enhanced and implemented
instead of:
  • my proposal getting rejected first, I research and document, I get more "but", I research and document more, rinse and repeat

It cannot get more obvious if you look at all the twiki-dev traffic on Item1964 and the benefits layed out at TWiki:Codev.PurposeOfUserHomePage#UserFriendly. Now compare that with discussion and time to acceptance with, say, Item1960 - WebRss lacks search options.

Imagine how much more value I could bring to the TWiki community if we could discuss openly, implement and move on.

Well, I spent 30 minutes on this research, better move on.

PS: I changed the summary to be more accurate what this is about.

-- PTh

This was reverted and postponed to minor

-- Kenneth

Not exactly. I consider this item as done. New bug items should be created for enhancements. I copied the doc from TWiki:TWiki.UserHomepageSupplement to the top of this page.

-- PTh

Summary Configurable user homepage layout
ReportedBy TWiki:Main.PeterThoeny

SVN Range Sat, 25 Mar 2006 build 9517
AppliesTo Engine

Priority Enhancement
CurrentState Closed

Checkins 9529 9530 9533 9536 9537 9538 9539 9540 9541 9542 9543 9544 9545 9546 9574
TargetRelease patch
Edit | Attach | Watch | Print version | History: r19 < r18 < r17 < r16 < r15 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r19 - 2006-04-01 - CrawfordCurrie
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2023 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback