On Tue, May 5, 2015 at 7:20 AM, Michael T. Pope <mp...@computer.org> wrote:
> On Fri, 17 Apr 2015 16:17:55 +0200
> Jonathan Aquilina <eagles051...@gmail.com> wrote:
> > If we opt to go with static pages we can setup a website repo and then
> > anyone can really make the changes then pull from the repo onto the
> > webserver.
>
> I have at last caught up with all the outstanding bugs that needed
> attention, so I have time to look at the website again. Keeping things
> simple, I have grabbed a copy of the existing www.freecol.org and
> committed
> it to the FreeCol git tree. It is about 45M (FreeCol git generally
> was about 300M), but I expect a fair portion of that is disconnected or
> outdated, so it can be slimmed down significantly. I plan to work on
> upload-the-website and upload-what-has-changed scripts quite soon, and
> perhaps some other release-support script/s some time before next
> release[1].
>
> The way forward then is for volunteers to work on cleaning up what we have
> in the git tree, with the aim of reaching a lightweight set of static
> pages. Once we are there, we can start adding more dynamic content
> like the project stats that Jonathan wants. I have to investigate what
> privileges will be needed to upload to the website, that may be tricky.
>
> I am hoping Jonathan and perhaps Caleb will have time to work on this.
>
> Cheers,
> Mike Pope
>
Mike, et. al.,
I have mixed feelings about putting everything up on the repository, but
I'm generally feeling positive about this change. The only thing I don't
like is having to deal with SF's Git implementation.
I don't have any real issue with the website being included with the
release (not that too many are offline these days, but you could view
everything offline if needed). We will need to weed out PHP file then
though as the end user's computer will not be able to process them unless
they already have a PHP install running to parse the pages (something we
definitely don't want to depend on).
Conversely, if we want eventual dynamic content delivered via PHP, then we
would need to weight that with the fact that some content is being
available openly. For instance storing even a temporary username and
password hardcoded into a PHP file is out. For instance a hardcoded
variable (IE <?php $user = "admin"; $pass = *some hash code here* ?>)
wouldn't work as even a rudimentary password protection for some
non-critical testing portion of the server. I wouldn't advise that type of
security be used in all but the most basic situations were something quick
needed to be implemented ASAP, but you get my drift.
Likewise, if there was some config file, that would need to be displayed as
is too. The localsettings.php in a WordPress install is an example of such
a file with personalized settings you wouldn't wanted added to the Git
repository.
As for permissions, that is also a tricky one.
WT,
Is that an issue with the question mark "?" in the file name to retrieve
GET variables.
Best,
--
*Caleb R. Williams*
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers
