plg wrote:
What would be really appreciated for 2.1:
...
* better way to manage user input data (to avoid security issues)
...
and
nicolas wrote:
plg wrote:
Propose a secure method to work with user data input (considering PHP 5 is required to run Piwigo), I know that's important for you :-)
I know that you will say something like that ! :-) Ok for me but just after gettex. ...
Where do we stand today on user input management today?
Offline
VDigital wrote:
Where do we stand today on user input management today?
postponed to 2.2
Offline
plg wrote:
VDigital wrote:
Where do we stand today on user input management today?
postponed to 2.2
so we should merge from brqnch 2.0 to trunk all the current check_input_parameters and pwg_token. Right ?
Otherwise we fallback to the CSRF issues
Offline
rvelices wrote:
plg wrote:
VDigital wrote:
Where do we stand today on user input management today?
postponed to 2.2
so we should merge from brqnch 2.0 to trunk all the current check_input_parameters and pwg_token. Right ?
Otherwise we fallback to the CSRF issues
Of course rvelices, that's in my afternoon planning (right now I'm propagating the new "add tags" widget to element_set*).
Tonight, I'll come here to write what's still in the TODO list before 2.1.0RC1 :-)
Offline
plg wrote:
rvelices wrote:
plg wrote:
postponed to 2.2so we should merge from brqnch 2.0 to trunk all the current check_input_parameters and pwg_token. Right ?
Otherwise we fallback to the CSRF issuesOf course rvelices, that's in my afternoon planning (right now I'm propagating the new "add tags" widget to element_set*).
Tonight, I'll come here to write what's still in the TODO list before 2.1.0RC1 :-)
But it could have be better to create branch 2.1 before and not merge that stuff to trunk. We have to unmerge it after !
Offline
nicolas wrote:
But it could have be better to create branch 2.1 before and not merge that stuff to trunk. We have to unmerge it after !
The branch must be created as late as possible to avoid multiple merge (and there will be many commits during the beta test period)
Offline
Copyright(C) 2008-2009 Piwigo Team http://piwigo.org
Don't forget 2008-2010!
;-)
Offline
rvelices wrote:
so we should merge from brqnch 2.0 to trunk all the current check_input_parameters and pwg_token. Right ?
Job's done in [Subversion] r5195. Quite a big commit, I heavily refactored the edit/delete comment feature (which is a really nice feature).
Offline
VDigital wrote:
Don't forget 2008-2010!
Job's done.
Offline
The features are "ready enough" for 2.1.0RC1. Last step is to make sure all strings have internationisation and are present in lang/en_UK/*.lang.php at least.
My current main task is:
1) to check all strings have i18n on my devs (I've asked nicolas and P@t to check also),
2) then fill lang/en_UK/*.lang.php
3) run tools/translation_analysis against 2.0 language files
4) communicate with translators to get their translation
RC1 should be available on 2010-03-26 I hope.
Offline
plg wrote:
The features are "ready enough" for 2.1.0RC1. Last step is to make sure all strings have internationisation and are present in lang/en_UK/*.lang.php at least.
My current main task is:
1) to check all strings have i18n on my devs (I've asked nicolas and P@t to check also),
2) then fill lang/en_UK/*.lang.php
3) run tools/translation_analysis against 2.0 language files
4) communicate with translators to get their translation
RC1 should be available on 2010-03-26 I hope.
Do we have a way to see which language strings are defined but never used ?
Offline
rvelices wrote:
Do we have a way to see which language strings are defined but never used ?
I've coded a script this morning to detect the keys used in *.php and *.tpl but not defined in language files.
I will add the detection to find language keys defined but not used.
You're right, cleaning is a good idea :-)
Offline
The main problem is that I can quite easily detect:
{'***'|translate} l10n('***') l10n_args('***',
BUT if the key is built dynamically, then it's much more complex to detect, of course:
$language_key = 'my language key'; l10n($language_key);
(just a trivial example, of course it's much more complex in the real code)
Offline
I thought it could be possible to release Piwigo 2.1.0 today BUT after a discussion with P@t, I've decided to postpone release 2.1.0 to monday 17th May 2010 (1 week in the future).
The reason is : Automatic Upgrade. P@t is currently improving the [extension by P@t] Piwigo Auto Upgrade to let users jump from 2.0.x to 2.1.0 and forget about the heavy manual upgrade procedure.
I won't have much time to work on Piwigo at the end of the week, but I will prepare the launch as much as possible (release notes, newsletters, prepare page changes on the website...)
Offline
just one simple question: will it be possible to upgrade from RC3 to the final release next monday? Or will I need a fresh install of 2.1?
Appreciate your feedback :)
Offline