So, options as I see it:

1. Cancel the meeeting for this month.
2. Hold it Tuesday without me. I'll still put together an agenda (I

have no inputs so far.) 3. Reschedule to another evening Wed - Friday.

I'd prefer option 3, but will live with your consensus.

3 works for me. It's election day here, too :-) So does 1...

Lyle

Rescheduling is OK with me.

73,

John KD6OZH

----- Original Message ----- From: "Jim Sanford" [email protected] To: "EAGLE" [email protected] Sent: Friday, November 03, 2006 01:20 UTC Subject: [eagle] [Fwd: Re: EaglePedia Upgrades/Enhancements]

Team: What are your choices regarding the TeamSpeak conference for Tuesday?

All: Thanks to Emily for all this work. I'm still digesting the note.

I wish to add a note regarding Dave Hartzell: Some of you remember me asking for help because I was spending too much time editing in EaglePedia. Dave stepped up to the plate and has been taking my delusions ("I want . . ..") and turning them into reality. This is incredibly valuable, and I am very grateful to Dave.

Finally, regarding the TeamSpeak conference for 7 November: I will not be able to make it. Tuesday is election day here in PA, and I also have a Township Planning Commission meeting that night -- which I have to run, since the Chairman is out of town. Monday is also out for me, since I need to attend the Board of Supervisors' meeting.

So, options as I see it:

1. Cancel the meeeting for this month.
2. Hold it Tuesday without me. I'll still put together an agenda (I

have no inputs so far.) 3. Reschedule to another evening Wed - Friday.

I'd prefer option 3, but will live with your consensus.

What say the team?

Thanks & 73, Jim [email protected]

Emily Clarke wrote:

...

I wanted to update you on EaglePedia, specifically about upgrades to the base MediaWiki software and about personnel. This is a rather long email to explain what changes will take place - I encourage all of you to read it and provide any feedback.

First of all I'd like you all to welcome Dave Hartzell N0GTD who is joining the team as co-sysop of EaglePedia. Most of you have had a chance to meet Dave at the Symposium - Dave, along with Eric, served to introduce speakers during presentations. Dave is on the IT staff at NASA Ames and is not a programmer, but Dave will take responsibility for the EaglePedia system administration which will free me up to concentrate on software development.

The EaglePedia core software desperately needs an upgrade. The current version is 1.5.0 and we are plagued by compatibility issues. I propose that the upgrade take place beginning on the day following the next Teamspeak conference (which I think will be the 7th of November - if not, let me know). We will have to shut down EaglePedia during the upgrade period. The details follow.

Over the past few days I have upgraded the staging server from 1.5.0 to 1.8.2 (current version) however it was not trivial. I basically had to upgrade to 1.5.7, then to 1.6.0 (which is very unstable but included database changes), then to 1.8.2 (which seems very stable but also introduced database changes.) At the 1.6.0 level the current configuration documents become unusable and it took almost a full day to resolve. To resolve it the Wiki had to be initialized from scratch, which creates new (blank) configuration settings. These were then changed to fit our configuration. From there upgrading to 1.8.2 had no issues. Since I now have a 1.8.2 set of configuration settings it is may be possible to upgrade from 1.5.7 to 1.8.2 directly - I will probably roll back the staging server and test this before upgrading. It will save several hours if we can.

There are a number of other changes that were required.

1. In 1.8.2 the core Monobook Skin was re-written. Our version of

Monobook skin was highly customized and had to be re-written. This was primarily to support the hierarchical menu structure in the left side menu.

2. Version 1.8.2 gives programmers access to a global user object

(1.5.0 kept the user object as a protected subclass of the global wiki object) so this now allows me to authenticate users. This is a much better solution - in the past I had to rely on a custom skin (MonoNoTabs) to be the default skin and have all registered users set their skin to Monobook. Now Monobook can be the default skin since I can turn off the tabs, search field and toolbox based on user authentication. We will no longer need to support the MonoNoTabs skin.

3. Unfortunately the additional buttons on the Edit Toolbar still

require modification of the EditPage code. There is a proposal to move this to the Monobook javascript code, but no work has been done for this and I don't agree with this implementation. My proposal to the MediaWiki community is to change this to a separate include file that will be easier to maintain, and this is what I have done for 1.8.2. I've submitted the proposed solution to MediaWiki.

4. Extensions were broken in 1.5.0. In 1.8.2 they work, and as a

result I have created one (and will create others) to do some of the security tasks for us. By moving this code into extensions we will be able to upgrade in the future without making changes to the base code (other than the Monobook and toolbar modifications.) The first extension I wrote will necessitate a change in protected pages, but adds functionality. The old function was:

      {{NoPublish}}

This used a template, and about three other files (Monobook, SkinTemplate and Skin) had to be extensively modified to detect and modify the existing page data. The new function is in one extension and uses the syntax:

      <restrict [group = somegroupname]>Restricted text ...

</restrict>

There are two advantages to this

* it can restrict all or part of a page depending on where the
  <restrict></restrict> tags are placed and
* the restriction can be lifted for an individual group.

Up to this point we haven't used groups, but we can. So for example, if you wanted something to be seen by Rick, Jim and Bob only Dave can create a group called "executive" and using <restrict group=executive>Some text...</restrict> only the executive team could see the restricted text - everyone else only sees a comment that there is a group restriction.

5. Additional extensions have been installed and tested. These include:

   • Citations - you can put in <ref>Some reference</ref> and then at the bottom of the page use <references/> to list the citations.
   • Inputbox - this will allow us to create a dedicated "Create New Article" page. Although not entirely needed, this will eliminate the confusion of searching for a page name and getting a "not found - click here to create".
   • CategoryTree - this dynamically produces a browse-able tree of categories down to individual articles. This eliminates the need to manually create the Eagle Project Categories tree page.
   • RequireCategory - this requires someone to enter a category name for a new article before it is saved. This way all articles ultimately are browse-able using the CategoryTree tool

   Other extensions can be installed if needed. See

http://meta.wikimedia.org/wiki/Extensions for a comprehensive list of additional extensions.

6. Non-native characters can be added - I've added an extension and

modified the edit page template to display groups of non-native characters that people may wish to insert. These are grouped as Latin-1, Greek, Math Symbols, Currency Symbols, Misc. Symbols and Geometric Shapes. Below the edit box the list will appear - if a user needs a Symbol, they merely click on it.

7. No integrated WYSIWYG Editor yet - unfortunately there is still no

viable WYSIWYG solution for generating Wiki markup that is reliable and supported. The WINOR project was abandoned and as near as I can tell there is only debate, but no real progress. Most disheartening, FCK still carries the warning that it may corrupt the document database (which would be fatal).

One solution I am considering is to provide FCK in a popup

window. The editor will operate in a separate window and when saved it will pipe input through some HTML to Wiki conversion utility to convert the HTML to Wiki markup and insert it into the editor window. At first glance CPAN has HTML::WikiConverter that could be used, but it would be better to have something written in PHP so that the process could use a memory pipe rather than having to write the HTML to a temp file, convert the file, and read it back in again. This is not trivial, and I'm not sure how much of a priority I should put on this.

73,

Emily

---

N1DID formerly W0EEC - CM87tm

Support Project OSCAR - http://www.projectoscar.net http://www.projectoscar.net%A0%A0%A0/

---

Via the Eagle mailing list courtesy of AMSAT-NA [email protected] http://amsat.org/mailman/listinfo/eagle

I recommend postponing it a day or week. Election day is a very big thing here at least for me. We also have a BOD telecon that evening which I also hope to get postponed.

On Nov 2, 2006, at 8:20 PM, Jim Sanford wrote:

Team: What are your choices regarding the TeamSpeak conference for Tuesday?

All: Thanks to Emily for all this work. I'm still digesting the note.

I wish to add a note regarding Dave Hartzell: Some of you remember me asking for help because I was spending too much time editing in EaglePedia. Dave stepped up to the plate and has been taking my delusions ("I want . . ..") and turning them into reality. This is incredibly valuable, and I am very grateful to Dave.

Finally, regarding the TeamSpeak conference for 7 November: I will not be able to make it. Tuesday is election day here in PA, and I also have a Township Planning Commission meeting that night -- which I have to run, since the Chairman is out of town. Monday is also out for me, since I need to attend the Board of Supervisors' meeting.

So, options as I see it:

1. Cancel the meeeting for this month.
2. Hold it Tuesday without me. I'll still put together an agenda (I

have no inputs so far.) 3. Reschedule to another evening Wed - Friday.

I'd prefer option 3, but will live with your consensus.

What say the team?

Thanks & 73, Jim [email protected]

Emily Clarke wrote:

...

I wanted to update you on EaglePedia, specifically about upgrades to the base MediaWiki software and about personnel. This is a rather long email to explain what changes will take place - I encourage all of you to read it and provide any feedback.

First of all I'd like you all to welcome Dave Hartzell N0GTD who is joining the team as co-sysop of EaglePedia. Most of you have had a chance to meet Dave at the Symposium - Dave, along with Eric, served to introduce speakers during presentations. Dave is on the IT staff at NASA Ames and is not a programmer, but Dave will take responsibility for the EaglePedia system administration which will free me up to concentrate on software development.

The EaglePedia core software desperately needs an upgrade. The current version is 1.5.0 and we are plagued by compatibility issues. I propose that the upgrade take place beginning on the day following the next Teamspeak conference (which I think will be the 7th of November - if not, let me know). We will have to shut down EaglePedia during the upgrade period. The details follow.

Over the past few days I have upgraded the staging server from 1.5.0 to 1.8.2 (current version) however it was not trivial. I basically had to upgrade to 1.5.7, then to 1.6.0 (which is very unstable but included database changes), then to 1.8.2 (which seems very stable but also introduced database changes.) At the 1.6.0 level the current configuration documents become unusable and it took almost a full day to resolve. To resolve it the Wiki had to be initialized from scratch, which creates new (blank) configuration settings. These were then changed to fit our configuration. From there upgrading to 1.8.2 had no issues. Since I now have a 1.8.2 set of configuration settings it is may be possible to upgrade from 1.5.7 to 1.8.2 directly - I will probably roll back the staging server and test this before upgrading. It will save several hours if we can.

There are a number of other changes that were required.

1. In 1.8.2 the core Monobook Skin was re-written. Our version of

Monobook skin was highly customized and had to be re-written. This was primarily to support the hierarchical menu structure in the left side menu.

2. Version 1.8.2 gives programmers access to a global user object

(1.5.0 kept the user object as a protected subclass of the global wiki object) so this now allows me to authenticate users. This is a much better solution - in the past I had to rely on a custom skin (MonoNoTabs) to be the default skin and have all registered users set their skin to Monobook. Now Monobook can be the default skin since I can turn off the tabs, search field and toolbox based on user authentication. We will no longer need to support the MonoNoTabs skin.

3. Unfortunately the additional buttons on the Edit Toolbar still

require modification of the EditPage code. There is a proposal to move this to the Monobook javascript code, but no work has been done for this and I don't agree with this implementation. My proposal to the MediaWiki community is to change this to a separate include file that will be easier to maintain, and this is what I have done for 1.8.2. I've submitted the proposed solution to MediaWiki.

4. Extensions were broken in 1.5.0. In 1.8.2 they work, and as a

result I have created one (and will create others) to do some of the security tasks for us. By moving this code into extensions we will be able to upgrade in the future without making changes to the base code (other than the Monobook and toolbar modifications.) The first extension I wrote will necessitate a change in protected pages, but adds functionality. The old function was:

      {{NoPublish}}

This used a template, and about three other files (Monobook, SkinTemplate and Skin) had to be extensively modified to detect and modify the existing page data. The new function is in one extension and uses the syntax:

      <restrict [group = somegroupname]>Restricted text ...

</restrict>

There are two advantages to this

* it can restrict all or part of a page depending on where the
  <restrict></restrict> tags are placed and
* the restriction can be lifted for an individual group.

Up to this point we haven't used groups, but we can. So for example, if you wanted something to be seen by Rick, Jim and Bob only Dave can create a group called "executive" and using <restrict group=executive>Some text...</restrict> only the executive team could see the restricted text - everyone else only sees a comment that there is a group restriction.

5. Additional extensions have been installed and tested. These

include:

* Citations - you can put in <ref>Some reference</ref> and  

then at the bottom of the page use <references/> to list the citations. * Inputbox - this will allow us to create a dedicated "Create New Article" page. Although not entirely needed, this will eliminate the confusion of searching for a page name and getting a "not found - click here to create". * CategoryTree - this dynamically produces a browse-able tree of categories down to individual articles. This eliminates the need to manually create the Eagle Project Categories tree page. * RequireCategory - this requires someone to enter a category name for a new article before it is saved. This way all articles ultimately are browse-able using the CategoryTree tool

Other extensions can be installed if needed. See http://meta.wikimedia.org/wiki/Extensions for a comprehensive list of additional extensions.

6. Non-native characters can be added - I've added an extension and

modified the edit page template to display groups of non-native characters that people may wish to insert. These are grouped as Latin-1, Greek, Math Symbols, Currency Symbols, Misc. Symbols and Geometric Shapes. Below the edit box the list will appear - if a user needs a Symbol, they merely click on it.

7. No integrated WYSIWYG Editor yet - unfortunately there is still no

viable WYSIWYG solution for generating Wiki markup that is reliable and supported. The WINOR project was abandoned and as near as I can tell there is only debate, but no real progress. Most disheartening, FCK still carries the warning that it may corrupt the document database (which would be fatal).

One solution I am considering is to provide FCK in a popup

window. The editor will operate in a separate window and when saved it will pipe input through some HTML to Wiki conversion utility to convert the HTML to Wiki markup and insert it into the editor window. At first glance CPAN has HTML::WikiConverter that could be used, but it would be better to have something written in PHP so that the process could use a memory pipe rather than having to write the HTML to a temp file, convert the file, and read it back in again. This is not trivial, and I'm not sure how much of a priority I should put on this.

73,

Emily

---

N1DID formerly W0EEC - CM87tm

Support Project OSCAR - http://www.projectoscar.net http://www.projectoscar.net%A0%A0%A0/

---

Via the Eagle mailing list courtesy of AMSAT-NA [email protected] http://amsat.org/mailman/listinfo/eagle