We are pleased to announce Campsite 2.3.1, a bug-fix release of 2.3.0.
Changes since 2.3.0 include:
* Installation fixes for Fedora
* Compatibility with PHP 5
* Administration interface bug fixes
* Updated Russian localization
* New sample template packages
* Much documentation added to the user manual and the INSTALL file
* Admin interface can now run on any port
* Template language fixes
I restarted the apache server and this seems to have fixed it.
I'm not sure yet why it went down.
John Pye wrote:
> The www.campware.org website seems to have died...
> Also code.campware.org...
> Great timing eh
>
> JP
>
> Paul Baranowski wrote:
>
>
>>We are pleased to announce Campsite 2.3.1, a bug-fix release of 2.3.0.
>>
>>Changes since 2.3.0 include:
>>
>> * Installation fixes for Fedora
>> * Compatibility with PHP 5
>> * Administration interface bug fixes
>> * Updated Russian localization
>> * New sample template packages
>> * Much documentation added to the user manual and the INSTALL file
>> * Admin interface can now run on any port
>> * Template language fixes
>>
>>To download:
>>http://sourceforge.net/project/showfiles.php?group_id=66936&package_id=65091
>>
>>For a detailed list of the bugs fixed, go here:
>>http://code.campware.org/projects/campsite/query?status=closed&milestone=2.3.1
>>
>>To file a bug:
>>http://code.campware.org/projects/campsite/newticket
>>
>>Also, feel free to drop by our new much-improved home page:
>>http://www.campware.org/en/camp/campsite_news/
>>
>>
>>Enjoy!
>>
>>The Campsite Team
>>
>>
>>
>
>
What was the last entry in the apache logs before it died?
JP
Paul Baranowski wrote:
>I restarted the apache server and this seems to have fixed it.
>
>I'm not sure yet why it went down.
>
>
>John Pye wrote:
>
>
>>The www.campware.org website seems to have died...
>>Also code.campware.org...
>>Great timing eh
>>
>>JP
>>
>>Paul Baranowski wrote:
>>
>>
>>
>>
>>>We are pleased to announce Campsite 2.3.1, a bug-fix release of 2.3.0.
>>>
>>>Changes since 2.3.0 include:
>>>
>>> * Installation fixes for Fedora
>>> * Compatibility with PHP 5
>>> * Administration interface bug fixes
>>> * Updated Russian localization
>>> * New sample template packages
>>> * Much documentation added to the user manual and the INSTALL file
>>> * Admin interface can now run on any port
>>> * Template language fixes
>>>
>>>To download:
>>>http://sourceforge.net/project/showfiles.php?group_id=66936&package_id=65091
>>>
>>>For a detailed list of the bugs fixed, go here:
>>>http://code.campware.org/projects/campsite/query?status=closed&milestone=2.3.1
>>>
>>>To file a bug:
>>>http://code.campware.org/projects/campsite/newticket
>>>
>>>Also, feel free to drop by our new much-improved home page:
>>>http://www.campware.org/en/camp/campsite_news/
>>>
>>>
>>>Enjoy!
>>>
>>>The Campsite Team
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
I am rewriting the code for adding a section and ran into some
potentially strange behaviour in the old code. The following discussion
deals with adding a section and clicking the box marked "Add this
section to all subscriptions".
There are two things that can happen when you click this box. If the
users do not currently subscriptions, then the start date is set to
"Today", and the "Paid Days" and "Days" are set to the publication
defaults.
If the users already have subscriptions to some sections, then it looks
at the current start date, paid days, and subscription days for the
other sections, takes these values from there and uses them for the new
section.
The problem is that each section can have different values, so its
picking these new values somewhat randomly.
Example 1: in this example everything will work fine. Suppose a user
has these subscriptions already:
Section Name Start Date Paid Days Days
============ ========== ========= ====
sports 2005-09-01 30 30
politics 2005-09-01 30 30
We add a new section (lets say "science"), it gets the same data no
matter what because all the other sections have the:
Section Name Start Date Paid Days Days
============ ========== ========= ====
sports 2005-09-01 30 30
politics 2005-09-01 30 30
science 2005-09-01 30 30
Example 2: things start getting weird. Suppose we start with
subscriptions that have different values for each section:
Section Name Start Date Paid Days Days
============ ========== ========= ====
sports 2005-01-01 365 365
politics 2005-09-01 30 30
Adding the new section will give the new section the values of the last row:
Section Name Start Date Paid Days Days
============ ========== ========= ====
sports 2005-01-01 365 365
politics 2005-09-01 30 30
science 2005-09-01 30 30
So the question is: why does it work this way? My guess as to why it
hasnt been any trouble so far is that no one uses the ability to change
subscriptions at the section-detail level.
If its true that no one uses the subscription sections, then can we get
rid of them? If its not true, speak up!
This is a known although undocummented issue. Usually subscription have all
sections start and end at the same dates so it's not a problem now. Anyway,
this can't be much improved, because we're talking about updating thousands of
subscriptions, you can't ask the user to chose the start and end date for each
one. The best you can do is default to a certain criteria: the newest, or
logest section subscription etc.
Mugur
--- Paul Baranowski wrote:
> I am rewriting the code for adding a section and ran into some
> potentially strange behaviour in the old code. The following discussion
> deals with adding a section and clicking the box marked "Add this
> section to all subscriptions".
>
> There are two things that can happen when you click this box. If the
> users do not currently subscriptions, then the start date is set to
> "Today", and the "Paid Days" and "Days" are set to the publication
> defaults.
>
> If the users already have subscriptions to some sections, then it looks
> at the current start date, paid days, and subscription days for the
> other sections, takes these values from there and uses them for the new
> section.
>
> The problem is that each section can have different values, so its
> picking these new values somewhat randomly.
>
> Example 1: in this example everything will work fine. Suppose a user
> has these subscriptions already:
>
> Section Name Start Date Paid Days Days
> ============ ========== ========= ====
> sports 2005-09-01 30 30
> politics 2005-09-01 30 30
>
> We add a new section (lets say "science"), it gets the same data no
> matter what because all the other sections have the:
>
> Section Name Start Date Paid Days Days
> ============ ========== ========= ====
> sports 2005-09-01 30 30
> politics 2005-09-01 30 30
> science 2005-09-01 30 30
>
> Example 2: things start getting weird. Suppose we start with
> subscriptions that have different values for each section:
>
> Section Name Start Date Paid Days Days
> ============ ========== ========= ====
> sports 2005-01-01 365 365
> politics 2005-09-01 30 30
>
> Adding the new section will give the new section the values of the last row:
>
> Section Name Start Date Paid Days Days
> ============ ========== ========= ====
> sports 2005-01-01 365 365
> politics 2005-09-01 30 30
> science 2005-09-01 30 30
>
>
> So the question is: why does it work this way? My guess as to why it
> hasnt been any trouble so far is that no one uses the ability to change
> subscriptions at the section-detail level.
>
> If its true that no one uses the subscription sections, then can we get
> rid of them? If its not true, speak up!
>
> - Paul
>
>
>
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com