* Map Life Facts V3.6

[Nick-V]

I think I now have integration between the FH and Map html files. I can see a link is added to the FAM pages directing to the Map pages.

1) It appears the map files need regenerating every time the web is recreated?

2) I can map addresses or places but have a security issue. In FH I only publish certain events (e.g. I show Birth but not Residence). The plugin currently appears to map all events so Residence is shown on the Map page.

3) There appear significant formatting differences. I've got close by changing the mapfacts.css as follows:

Code: Select all

/*
REMOVE THIS
body	{font-family:Arial,Helvetica,sans-serif;}
li	{font-size:small; padding-bottom:0.25em;}
h1	{font-family:Arial,Helvetica,sans-serif; background-color:rgb(255,255,204); padding-top:0.1em; padding-right:1em; padding-bottom:0.1em; padding-left:1em;}
a	{text-decoration:none;}

ADD THIS
h1	{ clear: both; height: auto; font-size: 20pt; font-weight: 700; margin-left: 20px; margin-right: 20px; margin-top: 20px; margin-bottom: 20px; border-style: solid; border-top-width: 1pt; border-right-width: 0px; border-bottom-width: 1pt; border-left-width: 0px; font-family: "Calibri"; color: #000000}

A PROBLEM REMAINS BECAUSE IN THE MAP HTML FILES <H1> IS USED FOR BOTH THE PAGE HEADING AND "Map of Locations for...." HEADING SO THE CSS IS NOT USED AS STANDARD FH PAGES. THE USE OF TAGS IN MAP FILES NEEDS SOME REVIEW.
*/

h1	{ clear: both; height: auto; font-size: 20pt; font-weight: 700; margin-left: 20px; margin-right: 20px; margin-top: 20px; margin-bottom: 20px; border-style: solid; border-top-width: 1pt; border-right-width: 0px; border-bottom-width: 1pt; border-left-width: 0px; font-family: "Calibri"; color: #000000}

#facts	{width:48%; float:left; padding-right:2%;}
#map	{width:50%; height:80%;}
.noinfoscrollbar {line-height:1.35; overflow:hidden; white-space:nowrap; }

[tatewise]

Thank you for your feedback Nick.

Could you please update your FH Version so it appears in the right-hand panel.
At the very top of this FHUG page click User Control Panel, then on the Profile tab select Family Historian Version 6 at the bottom and click Submit.

1) Yes, the maps need regenerating every time the website is recreated, because any of the Fact/Place/Address details may have changed, Report Templates changed, Individuals/Families changed, etc, etc...

2) Yes, the Plugin includes all Facts. It has a Privacy Filter for Living and Private flags. I have quickly looked at the possibility of automatically detecting which Facts to include/exclude. It is surprisingly difficult to use the Report Template settings, but it may be feasible to use the website HTML pages themselves to detect the Facts to include.

3) Yes, sorry, there are formatting differences, and a future version of the Plugin will try to make the map pages more closely match the style of the FH website pages. However, <h1> is only used for the "Map of Locations for...." heading and nowhere else.

[AdrianBruce]

As you might remember, I'm not a map user yet but it occurs to me that I might want to filter the events that go into a map so that I might have two maps (say ) for someone - one showing their residence type events and another showing several events associated with their military career.

I can't step through the process in my mind yet and apologies if the solution or impossibility is obvious but that's my idea.

[tatewise]

Adrian, I understand your thinking, but it does have difficulties for the Plugin.

Unlike Nick's case, where there are webpages or Report settings to work from, your idea would need a Plugin dialogue to select the Facts, and that is complicated by the unlimited number of user defined Custom Fact Sets and Custom Facts that might exist.

My suggestion is that you use File > Import/Export > Export > GEDCOM File and on that Gedcom use File > Split Tree Helper to filter Individuals and Facts, then run the Plugin on the resulting Gedcom.

[AdrianBruce]

... it does have difficulties for the Plugin.

No doubt!

Unlike Nick's case, where there are webpages or Report settings to work from, your idea would need a Plugin dialogue to select the Facts, and that is complicated by the unlimited number of user defined Custom Fact Sets and Custom Facts that might exist.
...

Hmm - I didn't realise the complexity. I had in mind the sort of event / attribute selection criteria seen in FH's reports - however, I suspect from what you say, that all the hard work to assemble the list has already been done in the native software at that point, not least to assemble the list of possible facts with which to update individuals. Work that I guess is not a/v to a plug-in and would therefore have to be reproduced.

I guess your export / split tree helper suggestion provides one possible way forward - I'd have to balance the work against the benefits and neither are completely clear to me right now.

Thanks though.......

[tatewise]

Yes, the Plugin would have to recreate from scratch a dialogue similar to the Report Options > Individual/Marriage Events/Attributes > List Only/Exclude List & Edit List options.

Another idea is to use the Publish > Create Website/CD/DVD wizard to select Individuals and Report Facts, then the Plugin Maps would only include the Facts selected, as for Nick's case above.

[Nick-V]

Mike, many thanks.

I think H1 is used in two places which is why the main heading screws up?

Code: Select all

<div id="header">
<img src="Joseph%20Muller%20Small.jpg" alt="logo" class="logo" />
[b]<h1>Family tree of Muller, Miller, Dessau, Veit, etc.</h1>[/b]
</div>
<div id="menubar">
<ul>
<li><span><a href="index.html">Home</a></span></li>
<li><span><a href="_contact.html">Contact</a></span></li>
<li><span><a href="_statistics.html">Statistics</a></span></li>
<li><span class="fhmenuend"><a href="_nameindex.html">Index</a></span></li>
</ul>
</div>

    [b]<h1>
      <a href='#' onclick='PresentMap()'>Map of Locations for Jacqueline Sandra VEIT</a>
    </h1>[/b]

[tatewise]

Ah, I see what you mean!
You have used the wizard Step 7: Presentation & Behaviour option for Header Text that also uses <h1> and is overlooked by the Plugin.
In the next Plugin version I should be able to take all those layouts into account.

BTW: What are the unusual (non-XHTML) and [ /b] tags associated with your <h1> tags?
Did you mean to use <b> and </b> bold tags?

FYI: I have a prototype update to the Plugin that automatically only includes Facts appearing in the FH created web pages. In the final version there will be a Web Page Map Options setting to enable a Fact Filter that will search all FH created web pages once to determine the allowed Facts. Otherwise, all Facts will be included as now.

[tatewise]

A quick experiment suggests the following changes give a much better layout.

In the map HTML pages the Map of Locations for... headers need the following tags derived from the FH web pages:

Code: Select all

  <div class="fhcontent fhpageInd">
    <h1 class="FhHdg1">
      <a href='#' onclick='PresentMap()'>Map of Locations for Ian MUNRO</a>
    </h1>
  </div>

The mapfacts.css can then be reduced to just the last few lines:

Code: Select all

#facts	{width:48%; float:left; padding-right:2%;}
#map	{width:50%; height:80%;}
.noinfoscrollbar {line-height:1.35; overflow:hidden; white-space:nowrap; }

[Nick-V]

Mike, thanks, I'm glad you can see something and have had some thoughts on excluding certain events.

I'm not aware I do anything special in step 7 of FH web generation that affects the H1 tag presented in the Map file. I don't know about the B tags either. Rather, in version 6 (and 5?) it seems CSS tags are used to control appearance in FH pages and I suspect the same use needs to be made of such tags in the Map files so the standard CSS applies.

For example here is an excerpt from an FH page (note the use of FhHdg1 and other such tags these days):

Code: Select all

<h1>Family tree of Muller, Miller, Dessau, Veit, etc.</h1>
</div>
<div id="menubar">
<ul>
<li><span><a href="index.html">Home</a></span></li>
<li><span><a href="_contact.html">Contact</a></span></li>
<li><span><a href="_statistics.html">Statistics</a></span></li>
<li><span class="fhmenuend"><a href="_nameindex.html">Index</a></span></li>
</ul>
</div>
<div class="fhcontent fhpageInd">
<div class="FhSeeAlso">
<p>See also</p>
<ul>
<li><a href='map3525.html'>Map of Locations for Ian Gerald VEIT</a></li>
<li>Ian VEIT's parents: <a href="fam31.html">Nicholas Daryl VEIT (1960- )</a> and <a href="fam31.html">Magdalena SIDORUK (1976- )</a></li>
<li>Ian VEIT's sister: <a href="ind17.html">Victoria Miriam VEIT (2004- )</a></li>
</ul>
</div>
<h1 class="FhHdg1">Ian Gerald VEIT (2010- )</h1>

[tatewise]

Perhaps a little explanation is required.
The Plugin does try to make map pages similar in style to FH created web pages.
It reads sections of XHTML from a web page and inserts them in all map pages.
(I know you have discovered some imperfections, but in defense there are many customisations to consider.)
e.g.
The Plugin copies almost all the <head> section.
The Plugin copies the <div id="header"> and <div id="menubar"> sections.

When you choose the wizard Step 7: Presentation & Behaviour option for Header Text that inserts a <h1> heading in the <div id="header"> of every FH created web page and so the Plugin copies that section including its <h1> tag into every map page.

If the Plugin did not do that, the Logo & Heading & Menu bar in the map pages would not match the FH web pages.

So you see, when you choose that wizard Step 7 option it affects the <div id="header"> section in not only FH web pages but also map pages.

I agree the fhstyle.css file (and any user defined custom CSS files) should define the style of both FH web pages and Plugin map pages, and to a large degree do so already.

My suggested change to use <div class="fhcontent fhpageInd"> <h1 class="FhHdg1"> borrowed from the FH web pages mirrors your suggestion, and I hope to implement that in the next version of the Plugin.

But remember, I am just an FH user like you, and offer my Plugins voluntarily and free of charge.
Likewise, you are welcome to write your own Plugins and offer them to other FH users.

[Nick-V]

Mike, your input and indeed efforts developing plugins for free are respected and much appreciated as are your prompt responses to my observations. If it were easy these things would be part of the package or laymen like me would write their own

I agree, using tags in the same manner as FH would be good. And I recognise there is a potential maintenance implication for any plugin developer and/or user when FH is updated! Generally I avoid customisation totally for this reason. As you know from another thread I am moving from PHPGEDVIEW and wondering about other simple package web page software.

I now understand more clearly what you are saying about step 7 of the Wizard and do not recall (however, I'm old and forgetful) that I had changed anything on the COLOURS button. Next time I generate I will set things back to Installation Settings and review.

[Nick-V]

After resetting at Step 7 I confirm the <B> tags have now gone...the same formatting issues remain as we probably expect. The <div id="header"> and H1 tags remains in both the FH and Map pages.

In particular the main heading has lines above and below (not on FH). No idea why...something else in the mystyle.css overriding the H1 possibly...experimenting further.

The "Map of Locations for..." is grey rather than black. Notably this is a link <A> in the MAP page but not in FH.

Not being a CSS expert I can't add much...

[tatewise]

The odd thing is they were NOT <b> and </b> XHTML bold tags.

They were BBCode and [ /b] bold tags used in these postings.

Are you sure they ever actually existed in the XHTML script files, or had you tried to embolden the <h1> header lines in the sample Code blocks to emphasise them when posting here?

[Nick-V]

Mike, yes I may have used B in the code tags. Sorry, new to this forum.

I've made some progress. Clearly, the same use as FH of all tags would be a good idea and adding the mystyle.css reference would be necessary where it exists. However, I had the two problems with headings:

When I remove the H1 tag from the mapfacts.css the main heading is absolutely the same as FH but the secondary heading changes for the worse.

I believe the secondary heading only differs because it is a (perhaps unnecessary) hyperlink in the map files and not in FH:

<a href='#' onclick='PresentMap()'>Map of Locations for HURRELL</a>

[tatewise]

No, the second heading is different because it does NOT have the <div class="fhcontent fhpageInd"> <h1 class="FhHdg1"> class tags that invoke the fhstyle.CSS styling.

When the revised Plugin incorporates that design change the map page heading will match the web page heading, with lines above and below, correctly indented, same font, etc.

The hyperlink in the map page heading resets the Google map to its original format, and has a slight effect on the heading text style to indicate it is an active link, but I may be able to alter that too.

[Nick-V]

OK...and also should invoke the optional mystyle.css (I guess FH don't want us messing with the standard CSS !).

[tatewise]

Yes, because the Plugin copies the <head> section from web pages into map pages and that is where any customising of CSS would normally be placed.

There is nothing to stop you customising fhstyle.css because it only affects your web site.
It is much the same as the wizard Step 8 customisation via the Advanced button, where you can add any script XHTML/CSS code you like.

But you will need to preserve your custom fhstyle.css file just like mystyle.css as it will get recreated every time the web site is recreated.

[Nick-V]

Thanks, understood.

[tatewise]

Hi Nick, try the attached updated Map Life Facts Plugin V3.6.2 dated 22 Feb 2015.

It should fix the style issues discussed above, and on the Web Page Map Options tab there is a Facts Filter option to restrict Facts to those appearing in web pages.

BTW: You can always revert to the Plugin Store V3.6 if you need to.

[Nick-V]

Thanks Mike...I appreciate your dedication and passion ! I've done some testing...

OK - I confirm that events are now filtered on map pages - it appears that events excluded from both family and individual pages (e.g. education) are now also excluded from map pages.

OK - I confirm the FH header section is copied including all three CSS references (mystyle.css included). Also, your new CSS file works fine for me so I don't need to replace mapfacts.css after each run. I note your have H1 defined in mapfacts.css but this entry would be ignored for me as both fhstyle.css and mystyle.css appear later in the map pages.

Note - I confirm the main header is perfect. There remains an issue with the second header which may be due to it being a hyperlink. I'm using standard FH colours as in fhstyle.css (text is black, hyperlinks are grey) - grey is what I am seeing incorrectly on the second header of map pages only. Does this heading need to be a hyperlink (if this is indeed the issue)?

[tatewise]

The mapfacts.css file has its own codes for body, .fhcontent, .FhHdg1, etc, because the Plugin can create map pages in isolation in a folder without any FH web pages or fhstyle.css, etc. It is much easier and does no harm to always create the same mapfacts.css file.

The 2nd <h1> heading has always been a hyperlink that restores the Google map pane to its original view, and that is why it is grey.

If you really need that 2nd heading to be black then it can be done as follows.
In wizard Step 7 use Advanced... button and in ...at the end of the <head> section: add:

Code: Select all

<style type="text/css">
 .FhHdg1 a:link {color: #000000;}
 .FhHdg1 a:visited {color: #000000;}
</style>

That will fix it, and relies on FH web pages never having <h1> hyperlinks.

[Nick-V]

Mike, thanks again for applying your knowledge to provide a solution.

It seems that none of the H1 headings on the reports I've selected (other than maps) are functional hyperlinks therefore your solution to make ALL H1 Hyperlinks (visited and not) the same as ALL non H1 Hyperlinks works just fine, thanks. I've put the 2 lines in the mystyle.css instead of the wizard as its a good single place for all such customisations.

Yes, I'm keen that all formatting is consistent and the site put together thoughtfully. I'm putting in a burst of effort and foresee that your input in this thread will help others...