WWW should be removed from list of default SOUR fields

[Eyolf Østrem]

The WWW tag is currently included in the default list of tags that can be added to a SOUR. As this results in incorrect GEDCOM code, it should be removed from the list (in includes/set_gedcom_defaults.php:134).

I consider this to be closely related to the issue with URLs in CALN fields not being made into clickable links, but as I understand it, that is virtually done, so I won't file a separate bug.

cf. discussion at http://webtrees.net/en/forums/9-request-for-new-feature/10307-request-option-to-add-url-when-creating-a-source

[kiwi (kiwi3685-deactivatedaccount)]

The "Quick facts" list referred to in row 134 is an admin configurable option. Its defaults exists as they are because we know from years of experience they are ones that are commonly used. It is therefore up to individual site admins to remove this if they prefer their members do not use it. The rights and wrongs of it are irrelevant in this context.

Therefore I cannot support this defined as a being "bug". A "wishlist" item perhaps.

Regarding the CAL issue, I do suggest you raise that as a bug, or perhaps again, a "wishlist" item, although its existence in the "Feature Requests" forum area should be sufficient. I'm not aware of any developer actually planning to change the current code for this, though I don't have strong views either way. I suspect a casual debate on the forum may have been misinterpreted as a firm commitment to change it.

[Eyolf Østrem (eyolf)]

This begins to feel like a Catch 22. I raised the issue in the forum thread because it found it strange that the only way I could add a WWW field to a source was by going back to it AFTER creation (if I remembered to do it), and not in the initial window where it was first created.
It then became clear, through the discussion, (1) that the GEDCOM that is produced from this is not according to the standard. and (2) that there is a more legitimate place for this, namely the CALN field.
If we're now back to saying that standards-compliant code isn't all that important, then I'm also back to wishing that a WWW field be available at creation-time, although I think it would be better to keep to the standard, especially since there does not seem to be any compelling reason not do do so.

About the CAL issue: in the forum thread from November 2010 which was referred to in the current thread, It seemed that the only thing which might stand in the way of automatic creation of links was if it was a security issue, but nobody (including greg) could see any such issue.

And about this being admin configurable: yes, but currently, webtrees will with the default setting produce erroneous gedcom code. That's more serious than, say, allowing admins to do stupid things.

[kiwi (kiwi3685-deactivatedaccount)]

<<It seemed that the only thing which might stand in the way >>That's often the mistake made in forum discussions. There is another far more important obstacle - finding a developer with both the time and the interest to do it, even if the development team as a whole agree with the concept (and we haven't discussed it). What you can take from that discussion is that there may be no major obstacle EVENTUALLY, but for now it would be incredibly low on anyone's priority list. So whether you want to leave it on the Feature Requests forum (which we look through from time to time), or add it as a "wishlist" item here is up to you.

As for the WWW, I ONLY referred to its inclusion as a an admin-configurable quick-link. As I said "The rights and wrongs of it are irrelevant in this context." Any admin who wants to remove it can. I (personally) have no interest in the GEDCOM-standards debate in this regard, which is also why I had no further comment to make on the debate.

[Eyolf Østrem (eyolf)]

Of course, I fully respect the committment and the priorities of the dev team - you do a great job!

[fisharebest (fisharebest)]

FYI, I submitted the "make the CALN field clickable" update earlier today. It will be included in 1.1.2 - which is planned for next weekend.

I've been thinking about the WWW issue.

We must strike a balance between guiding users into producing standards-compliant, well-structured data - and providing a "usable application".

There are many other cases where we allow (or even actively encourage!) non-standard structures. e.g.

1 BIRT / 2 DATE / 3 TIME
1 BURI / 2 CEME
1 ADDR (instead of 1 RESI / 2 ADDR)

Since many of these are generated by other applications, it is pointless trying to discourage them in webtrees.

As we have discussed, it would be better to encourage people to put URLs in the PAGE field of the citation. These have the advantage of being displayed with the sourced fact - rather than only on the source. Perhaps a WIKI page on "how to use sources, citations and repositories" could cover this?

But on balance, I agree, and have updated the defaults.

[kiwi (kiwi3685-deactivatedaccount)]

<<But on balance, I agree, and have updated the defaults.>>

Thanks for your support! I disagree.

I also note you liberally changed other defaults in this area, most of which I also disagree with. These should have been discussed properly among the development team, as that is how these defaults were established months ago.

[fisharebest (fisharebest)]

<<I disagree>>

My apologies. You marked this as "wishlist", and I misread <<I don't have strong views either way>> as applying to this issue, not the CALN issue.

If you do have strong views on this, please add it back.

<<I also note you liberally changed other defaults in this area>>

I removed both WWW/EMAIL, because the logic for one applies equally to the other.

I removed OBJE, because it is not necessary. Immediately below the "Add facts" area is an "Add media object" area. Having two identical links, on two adjacent lines seemed a source of confusion. We don't add media objects using the "Add fact" link elsewhere.

[Eyolf Østrem (eyolf)]

I've made a first draft of a wiki page about Citations, Sources, and Repos, as greg suggested.

http://wiki.webtrees.net/Using_Sources,_Citations,_and_Repositories

I realised that the CALN solution is only relevant if the source is naturally part of a repository. For a standalone site, the Publication (PUBL) field might be more appropriate, but URLs there are not currently linkified.

[fisharebest (fisharebest)]

Fix released in webtrees 1.1.2