phppgadmin-devel — For Developers Only

Re: [ppa-dev] Table action buttons not working after editing row

[Ian L. B. <ba...@gm...>]

2013/2/19 Jehan-Guillaume (ioguix) de Rorthais <io...@fr...>
>
> On 18/02/2013 15:01, Ian Lawrence Barwick wrote:
> >
> > 2013/2/18 Jehan-Guillaume (ioguix) de Rorthais <io...@fr...
> > <mailto:io...@fr...>>
> >
> >     On 17/02/2013 00:12, Ian Lawrence Barwick wrote:
> >     > 2013/2/13 Jehan-Guillaume (ioguix) de Rorthais <io...@fr...
> >     <mailto:io...@fr...>>:
> >     >> On 11/02/2013 05:29, Ian Lawrence Barwick wrote:
> >     >>> 2013/2/9 Ian Lawrence Barwick <ba...@gm...
> >     <mailto:ba...@gm...>>:
> >     > (...)
> >     >>> I've spent a bit more time looking at this and while I don't yet
> >     have
> >     >>> any concrete
> >     >>> suggestions, the way the link generation is being handled is
> >     certainly not
> >     >>> optimal :( It seems pretty much all the POST data is getting
> >     included in some
> >     >>> of the URLs generated after form submission.
> >     >>
> >     >> Agree, this is quite a bad patch. I hadn't check all consequences...
> >     >>
> >     >> I'll revert it.
> >     >>
> >     >>> E.g. if you edit a record on a table, after submitting the form, in
> >     >>> the "browse" view
> >     >>> the table header links to sort columns also now contain all the data
> >     >>> submitted from
> >     >>> the form.
> >     >>
> >     >> Exactly.
> >     >>
> >     >>> I'll continue looking into it, it's useful to find out how
> >     things fit
> >     >>> together anyway.
> >     >>
> >     >> I'll try to revert this patch quickly, so we can work on a
> >     "clean" code.
> >     >
> >     > Have you been able to revert this patch? I've got an idea for a plugin
> >     > I'd like to write which would be useful for me to get to know how
> >     > the PPA code works and what the actual issues are.
> >
> >     Not yet :/
> >     I hope I'll be able to deal with this during the week.
> >
> >     Stay tuned;)
> >
> >
> > No worries, thanks :)
>
> Committed !

Apologies for the stupid question, but where can I see the commit?

Is this the correct repository?

https://github.com/phppgadmin/phppgadmin/commits/master

Thanks

Ian Barwick

Re: [ppa-dev] What to do about bytea bug...

[Jehan-Guillaume (i. de R. <io...@fr...>]

On 19/02/2013 17:56, Lou Picciano wrote:
> I've only been following this conversation peripherally; sorry if the
> comment is impertinent, but: Might not a lot of these issues be solved
> with creative detection of pg_server_version and manipulation of
> byte_output?

Yes, this will be part of the patch, be we need to decide either we
force a specific bytea_output or leave the choice to the user in the
conf file for version >= 9.0.

> Lou Picciano
> 
> ----- Original Message -----
> From: Jehan-Guillaume (ioguix) de Rorthais <io...@fr...>
> To: Karl O. Pinc <ko...@me...>
> Cc: php...@li...
> Sent: Tue, 19 Feb 2013 16:14:11 -0000 (UTC)
> Subject: Re: [ppa-dev] What to do about bytea bug...
> 
> On 19/02/2013 15:54, Karl O. Pinc wrote:
>> On 02/19/2013 08:13:00 AM, phb07 wrote:
>>> Hi all,
>>>
>>> Please note that the hex format is not always what users need. I
>>> large
>>>
>>> customer I am working with (with many ppa users) needs to see and
>>> edit
>>>
>>> values like 'ABC\001\002DEF', because such structured data are
>>> meaningful for users. In these cases, only managing hex
>>> representation
>>>
>>> would be a large regression.
>>
>> 2 data formats are not bad.  
>>
>> But, in your representation above, how does the code know what
>> to escape and what to represent as text?  The
>> locale/charset must fit into this somewhere, and there's
>> 2 locale/charsets; one in the db and one on the client.
>>
>> How, exactly, would it be done?
> 
> This format is simply the plain old 'escape' format of postgres. It is
> working fine and the way Philippe shows in PPA with PostgreSQL up to 8.4.
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> phpPgAdmin-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phppgadmin-devel

Re: [ppa-dev] What to do about bytea bug...

[Lou P. <lou...@co...>]

I've only been following this conversation peripherally; sorry if the comment is impertinent, but: Might not a lot of these issues be solved with creative detection of pg_server_version and manipulation of byte_output?

Lou Picciano

----- Original Message -----
From: Jehan-Guillaume (ioguix) de Rorthais <io...@fr...>
To: Karl O. Pinc <ko...@me...>
Cc: php...@li...
Sent: Tue, 19 Feb 2013 16:14:11 -0000 (UTC)
Subject: Re: [ppa-dev] What to do about bytea bug...

On 19/02/2013 15:54, Karl O. Pinc wrote:
> On 02/19/2013 08:13:00 AM, phb07 wrote:
>> Hi all,
>>
>> Please note that the hex format is not always what users need. I 
>> large
>>
>> customer I am working with (with many ppa users) needs to see and 
>> edit
>>
>> values like 'ABC\001\002DEF', because such structured data are 
>> meaningful for users. In these cases, only managing hex 
>> representation
>>
>> would be a large regression.
> 
> 2 data formats are not bad.  
> 
> But, in your representation above, how does the code know what 
> to escape and what to represent as text?  The
> locale/charset must fit into this somewhere, and there's
> 2 locale/charsets; one in the db and one on the client.
> 
> How, exactly, would it be done?

This format is simply the plain old 'escape' format of postgres. It is
working fine and the way Philippe shows in PPA with PostgreSQL up to 8.4.

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
phpPgAdmin-devel mailing list
php...@li...
https://lists.sourceforge.net/lists/listinfo/phppgadmin-devel

Re: [ppa-dev] What to do about bytea bug...

[Jehan-Guillaume (i. de R. <io...@fr...>]

On 19/02/2013 15:54, Karl O. Pinc wrote:
> On 02/19/2013 08:13:00 AM, phb07 wrote:
>> Hi all,
>>
>> Please note that the hex format is not always what users need. I 
>> large
>>
>> customer I am working with (with many ppa users) needs to see and 
>> edit
>>
>> values like 'ABC\001\002DEF', because such structured data are 
>> meaningful for users. In these cases, only managing hex 
>> representation
>>
>> would be a large regression.
> 
> 2 data formats are not bad.  
> 
> But, in your representation above, how does the code know what 
> to escape and what to represent as text?  The
> locale/charset must fit into this somewhere, and there's
> 2 locale/charsets; one in the db and one on the client.
> 
> How, exactly, would it be done?

This format is simply the plain old 'escape' format of postgres. It is
working fine and the way Philippe shows in PPA with PostgreSQL up to 8.4.

Re: [ppa-dev] What to do about bytea bug...

[Karl O. P. <ko...@me...>]

On 02/19/2013 08:13:00 AM, phb07 wrote:
> Hi all,
> 
> Please note that the hex format is not always what users need. I 
> large
> 
> customer I am working with (with many ppa users) needs to see and 
> edit
> 
> values like 'ABC\001\002DEF', because such structured data are 
> meaningful for users. In these cases, only managing hex 
> representation
> 
> would be a large regression.

2 data formats are not bad.  

But, in your representation above, how does the code know what 
to escape and what to represent as text?  The
locale/charset must fit into this somewhere, and there's
2 locale/charsets; one in the db and one on the client.

How, exactly, would it be done?



Karl <ko...@me...>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

Re: [ppa-dev] What to do about bytea bug...

[phb07 <ph...@ap...>]

Hi all,

Please note that the hex format is not always what users need. I large 
customer I am working with (with many ppa users) needs to see and edit 
values like 'ABC\001\002DEF', because such structured data are 
meaningful for users. In these cases, only managing hex representation 
would be a large regression.

This said, code corrupting data cannot remains as is...

Regards.
Philippe Beaudoin.

Le 19/02/2013 11:38, Jehan-Guillaume (ioguix) de Rorthais a écrit :
> On 19/02/2013 02:57, Karl O. Pinc wrote:
>> On 02/18/2013 06:27:46 PM, Jehan-Guillaume (ioguix) de Rorthais wrote:
>>
>>> We can not know what was the original input format. So in my opinion,
>>> we
>>> should add a parameter to handle bytea_output in config.inc.php and
>>> make
>>> this a user decision. Presently, we just force it to 'hex' and
>>> corrupt
>>> it on the way. The other option is to pick 'hex' (thus, keep using
>>> pg_escape_bytea), but fix the way we print it.
>> Hex is the canonical pg representation so IMHO we will at least
>> want the option to display/edit in hex.  Since we're doing
>> hex anyway then for the moment just do everything in hex.
> Yeah, we are doing 'hex' with 9.0+, but without really noticing it
> before now.
>
> 'hex' is the fastest format anyway. And only supporting 'hex' correctly
> for 9.0+ is probably the easiest and quickest patch.
>
> I might not have time to work on this before one or two weeks, but I'll
> try...unless someone else could jump on this issue as we have a strategy
> now. I'll be able to review any patch for sure.
>
>> Later a config parameter can be added (if we want to go there)
>> if some other external representation is desired.
>>
>> (Frankly, since there are
>> virtually an infinite number of things that could be
>> encoded in bytea having a fixed list of acceptable
>> external representation does not make sense.
>> If the user wants to display their binary data in a certain
>> way then ppa should have have a plugin
>> architecture that hand the job off to something outside of
>> ppa.)
> Well, fetching and displaying is not just about that. We need to fetch
> the data and print them in fields as well, to edit rows.
>
> My concerned is not pretty printing binary stuff. It's just to not
> corrupt them when editing a row (inserting is the matter of the user).
>
>> Karl <ko...@me...>
>> Free Software:  "You don't pay back, you pay forward."
>>                   -- Robert A. Heinlein
>>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> phpPgAdmin-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phppgadmin-devel
>
>

Re: [ppa-dev] What to do about bytea bug...

[Karl O. P. <ko...@me...>]

On 02/19/2013 04:38:58 AM, Jehan-Guillaume (ioguix) de Rorthais wrote:
> On 19/02/2013 02:57, Karl O. Pinc wrote:
> > On 02/18/2013 06:27:46 PM, Jehan-Guillaume (ioguix) de Rorthais

> > (Frankly, since there are
> > virtually an infinite number of things that could be
> > encoded in bytea having a fixed list of acceptable
> > external representation does not make sense.
> > If the user wants to display their binary data in a certain
> > way then ppa should have have a plugin
> > architecture that hand the job off to something outside of
> > ppa.)
> 
> Well, fetching and displaying is not just about that. We need to 
> fetch
> the data and print them in fields as well, to edit rows.

Sure.  Same logic apples to editing as to display/print.



Karl <ko...@me...>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

Re: [ppa-dev] What to do about bytea bug...

[Jehan-Guillaume (i. de R. <io...@fr...>]

On 19/02/2013 02:57, Karl O. Pinc wrote:
> On 02/18/2013 06:27:46 PM, Jehan-Guillaume (ioguix) de Rorthais wrote:
> 
>> We can not know what was the original input format. So in my opinion,
>> we
>> should add a parameter to handle bytea_output in config.inc.php and
>> make
>> this a user decision. Presently, we just force it to 'hex' and 
>> corrupt
>> it on the way. The other option is to pick 'hex' (thus, keep using
>> pg_escape_bytea), but fix the way we print it.
> 
> Hex is the canonical pg representation so IMHO we will at least
> want the option to display/edit in hex.  Since we're doing
> hex anyway then for the moment just do everything in hex.

Yeah, we are doing 'hex' with 9.0+, but without really noticing it
before now.

'hex' is the fastest format anyway. And only supporting 'hex' correctly
for 9.0+ is probably the easiest and quickest patch.

I might not have time to work on this before one or two weeks, but I'll
try...unless someone else could jump on this issue as we have a strategy
now. I'll be able to review any patch for sure.

> Later a config parameter can be added (if we want to go there) 
> if some other external representation is desired.  
> 
> (Frankly, since there are
> virtually an infinite number of things that could be
> encoded in bytea having a fixed list of acceptable
> external representation does not make sense.
> If the user wants to display their binary data in a certain
> way then ppa should have have a plugin
> architecture that hand the job off to something outside of
> ppa.)

Well, fetching and displaying is not just about that. We need to fetch
the data and print them in fields as well, to edit rows.

My concerned is not pretty printing binary stuff. It's just to not
corrupt them when editing a row (inserting is the matter of the user).

> Karl <ko...@me...>
> Free Software:  "You don't pay back, you pay forward."
>                  -- Robert A. Heinlein
> 

Re: [ppa-dev] What to do about bytea bug...

[Karl O. P. <ko...@me...>]

On 02/18/2013 06:27:46 PM, Jehan-Guillaume (ioguix) de Rorthais wrote:

> We can not know what was the original input format. So in my opinion,
> we
> should add a parameter to handle bytea_output in config.inc.php and
> make
> this a user decision. Presently, we just force it to 'hex' and 
> corrupt
> it on the way. The other option is to pick 'hex' (thus, keep using
> pg_escape_bytea), but fix the way we print it.

Hex is the canonical pg representation so IMHO we will at least
want the option to display/edit in hex.  Since we're doing
hex anyway then for the moment just do everything in hex.

Later a config parameter can be added (if we want to go there) 
if some other external representation is desired.  

(Frankly, since there are
virtually an infinite number of things that could be
encoded in bytea having a fixed list of acceptable
external representation does not make sense.
If the user wants to display their binary data in a certain
way then ppa should have have a plugin
architecture that hand the job off to something outside of
ppa.)



Karl <ko...@me...>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

Re: [ppa-dev] What to do about bytea bug...

[Jehan-Guillaume (i. de R. <io...@fr...>]

On 24/01/2013 14:08, Jehan-Guillaume (ioguix) de Rorthais wrote:
> On 24/01/2013 06:03, Robert Treat wrote:
>> I spoke with ioguix a few days ago on irc about releasing a new 
>> version of PPA, and that I had hoped to take another crack at
>> solving the bytea problem. For those not familiar with it, the
>> quick summary is that if you attempt to insert or edit bytea data
>> via PPA, it will modify the data so that essentially you end up
>> with corrupted data. Unfortunately, the way PPA works, just editing
>> another field of a bytea row will also cause PPA to also update the
>> bytea column, as we update all values for a given row when any
>> value is updated.
>>
>> Now, I've tried a few different methods of trying to fix this, but 
>> could come up with no working set of escape and unescape options
>> that would prevent this. (And as a note, it's made trickier because
>> you have to support multiple encoding formats, though I came up
>> with workarounds for that). At this point, I'm somewhat of the
>> opinion it can't be done. Now, I'd be happy for someone else to
>> take a look and show me the error of my ways, but barring that,
>> I've spent the last few days trying to come up with a work-around.
> 
> I'll give it a try and come back to you.

I finally gave it a swing.

My understanding is that pg_escape_string is ONLY appropriate for data
insertion and will ALWAYS returns data in 'escape' format for pg <9.0
and 'hex' for greater ones. On insertion, the backend auto detect 'hex'
or 'escaped' format depending if the string begins with \x (for hex) or not.
So, if you have pure, raw data, use pg_escape_bytea to escape it and the
backend will detect the format as 'hex'.

For insertion, my opinion is to leave the user mess with this. PPA is
not aimed to edit bytea fields. If the user wants/needs to edit them,
then he needs to deal with this himself.

Now, fetching bytea for a form or just to display them. The only place
we play with bytea values is for displaying them and we are using
pg_escape_bytea there which only returns data in... 'hex' format.

If the user inserted a 'ff', he will get a 'ff' with pgsql <9.0 and
'\x3636' with 9.0+. Worst, in "$data->escapeBytea" after calling
pg_escape_bytea, we removes backslash, so we finally get 'x3636' which
is then corrupted as it will be detected as a 'escape' format on UPDATE.

We can not know what was the original input format. So in my opinion, we
should add a parameter to handle bytea_output in config.inc.php and make
this a user decision. Presently, we just force it to 'hex' and corrupt
it on the way. The other option is to pick 'hex' (thus, keep using
pg_escape_bytea), but fix the way we print it.

I hope I was clear enought. I'm done for tonight, too tired to get any
further. hopefully this mail will be helpful!

cheers,

Re: [ppa-dev] Table action buttons not working after editing row

[Jehan-Guillaume (i. de R. <io...@fr...>]

On 18/02/2013 15:01, Ian Lawrence Barwick wrote:
> 
> 2013/2/18 Jehan-Guillaume (ioguix) de Rorthais <io...@fr...
> <mailto:io...@fr...>>
> 
>     On 17/02/2013 00:12, Ian Lawrence Barwick wrote:
>     > 2013/2/13 Jehan-Guillaume (ioguix) de Rorthais <io...@fr...
>     <mailto:io...@fr...>>:
>     >> On 11/02/2013 05:29, Ian Lawrence Barwick wrote:
>     >>> 2013/2/9 Ian Lawrence Barwick <ba...@gm...
>     <mailto:ba...@gm...>>:
>     > (...)
>     >>> I've spent a bit more time looking at this and while I don't yet
>     have
>     >>> any concrete
>     >>> suggestions, the way the link generation is being handled is
>     certainly not
>     >>> optimal :( It seems pretty much all the POST data is getting
>     included in some
>     >>> of the URLs generated after form submission.
>     >>
>     >> Agree, this is quite a bad patch. I hadn't check all consequences...
>     >>
>     >> I'll revert it.
>     >>
>     >>> E.g. if you edit a record on a table, after submitting the form, in
>     >>> the "browse" view
>     >>> the table header links to sort columns also now contain all the data
>     >>> submitted from
>     >>> the form.
>     >>
>     >> Exactly.
>     >>
>     >>> I'll continue looking into it, it's useful to find out how
>     things fit
>     >>> together anyway.
>     >>
>     >> I'll try to revert this patch quickly, so we can work on a
>     "clean" code.
>     >
>     > Have you been able to revert this patch? I've got an idea for a plugin
>     > I'd like to write which would be useful for me to get to know how
>     > the PPA code works and what the actual issues are.
> 
>     Not yet :/
>     I hope I'll be able to deal with this during the week.
> 
>     Stay tuned;)
> 
> 
> No worries, thanks :)

Committed !

> 
> Ian Barwick 

Re: [ppa-dev] Table action buttons not working after editing row

[Ian L. B. <ba...@gm...>]

2013/2/18 Jehan-Guillaume (ioguix) de Rorthais <io...@fr...>

> On 17/02/2013 00:12, Ian Lawrence Barwick wrote:
> > 2013/2/13 Jehan-Guillaume (ioguix) de Rorthais <io...@fr...>:
> >> On 11/02/2013 05:29, Ian Lawrence Barwick wrote:
> >>> 2013/2/9 Ian Lawrence Barwick <ba...@gm...>:
> > (...)
> >>> I've spent a bit more time looking at this and while I don't yet have
> >>> any concrete
> >>> suggestions, the way the link generation is being handled is certainly
> not
> >>> optimal :( It seems pretty much all the POST data is getting included
> in some
> >>> of the URLs generated after form submission.
> >>
> >> Agree, this is quite a bad patch. I hadn't check all consequences...
> >>
> >> I'll revert it.
> >>
> >>> E.g. if you edit a record on a table, after submitting the form, in
> >>> the "browse" view
> >>> the table header links to sort columns also now contain all the data
> >>> submitted from
> >>> the form.
> >>
> >> Exactly.
> >>
> >>> I'll continue looking into it, it's useful to find out how things fit
> >>> together anyway.
> >>
> >> I'll try to revert this patch quickly, so we can work on a "clean" code.
> >
> > Have you been able to revert this patch? I've got an idea for a plugin
> > I'd like to write which would be useful for me to get to know how
> > the PPA code works and what the actual issues are.
>
> Not yet :/
> I hope I'll be able to deal with this during the week.
>
> Stay tuned;)


No worries, thanks :)

Ian Barwick

Re: [ppa-dev] Table action buttons not working after editing row

[Jehan-Guillaume (i. de R. <io...@fr...>]

On 17/02/2013 00:12, Ian Lawrence Barwick wrote:
> 2013/2/13 Jehan-Guillaume (ioguix) de Rorthais <io...@fr...>:
>> On 11/02/2013 05:29, Ian Lawrence Barwick wrote:
>>> 2013/2/9 Ian Lawrence Barwick <ba...@gm...>:
> (...)
>>> I've spent a bit more time looking at this and while I don't yet have
>>> any concrete
>>> suggestions, the way the link generation is being handled is certainly not
>>> optimal :( It seems pretty much all the POST data is getting included in some
>>> of the URLs generated after form submission.
>>
>> Agree, this is quite a bad patch. I hadn't check all consequences...
>>
>> I'll revert it.
>>
>>> E.g. if you edit a record on a table, after submitting the form, in
>>> the "browse" view
>>> the table header links to sort columns also now contain all the data
>>> submitted from
>>> the form.
>>
>> Exactly.
>>
>>> I'll continue looking into it, it's useful to find out how things fit
>>> together anyway.
>>
>> I'll try to revert this patch quickly, so we can work on a "clean" code.
> 
> Have you been able to revert this patch? I've got an idea for a plugin
> I'd like to write which would be useful for me to get to know how
> the PPA code works and what the actual issues are.

Not yet :/
I hope I'll be able to deal with this during the week.

Stay tuned;)

> Thanks
> 
> Ian Barwick

Re: [ppa-dev] Table action buttons not working after editing row

[Ian L. B. <ba...@gm...>]

2013/2/13 Jehan-Guillaume (ioguix) de Rorthais <io...@fr...>:
> On 11/02/2013 05:29, Ian Lawrence Barwick wrote:
>> 2013/2/9 Ian Lawrence Barwick <ba...@gm...>:
(...)
>> I've spent a bit more time looking at this and while I don't yet have
>> any concrete
>> suggestions, the way the link generation is being handled is certainly not
>> optimal :( It seems pretty much all the POST data is getting included in some
>> of the URLs generated after form submission.
>
> Agree, this is quite a bad patch. I hadn't check all consequences...
>
> I'll revert it.
>
>> E.g. if you edit a record on a table, after submitting the form, in
>> the "browse" view
>> the table header links to sort columns also now contain all the data
>> submitted from
>> the form.
>
> Exactly.
>
>> I'll continue looking into it, it's useful to find out how things fit
>> together anyway.
>
> I'll try to revert this patch quickly, so we can work on a "clean" code.

Have you been able to revert this patch? I've got an idea for a plugin
I'd like to write which would be useful for me to get to know how
the PPA code works and what the actual issues are.

Thanks

Ian Barwick

Re: [ppa-dev] Table action buttons not working after editing row

[Jehan-Guillaume (i. de R. <io...@fr...>]

On 11/02/2013 05:29, Ian Lawrence Barwick wrote:
> 2013/2/9 Ian Lawrence Barwick <ba...@gm...>:
>> 2013/2/7 Jehan-Guillaume (ioguix) de Rorthais <io...@fr...>:
>>> On 01/02/2013 12:07, Jehan-Guillaume (ioguix) de Rorthais wrote:
>>>> On 01/02/2013 11:19, Ian Lawrence Barwick wrote:
> (...)
>>>>> It looks like the parameters from the POST request are being used
>>>>> indiscriminately to populate the links, in display.php/
>>>>> doBrowse(). The array errors are ugly but don't appear to be
>>>>> critical; the actual problem seems to be that the generated link
>>>>> contains "action=editrow", rather than what appears to be the
>>>>> correct "action=confeditrow".
>>>>>
>>>>> I'm not entirely sure how the code fits together right now so
>>>>> haven't got any patches. Possibly the links should be generated
>>>>> using a whitelist to select the parameters to be used?
>>>>
>>>> Mh, the problem is that we don't know what parameters plugins will
>>>> have to add, and I'm not sure we should add a specific API to allow
>>>> them to register parameters to this whitelist.
>>>>
>>>> This part of the code need some more thoughts and refactoring, for sure:
>>>>
>>>> +               // Build array OF parameters for sorts/pages links
>>>> +               $_gets = $_REQUEST;
>>>> +               unset($_gets['query']);
>>>> +               unset($_gets['MAX_FILE_SIZE']);
>>>
>>> I am considering to revert this patch to original code and find another
>>> cleaner way to make the plugin Reports works correctly.
>>>
>>> Thoughts ?
>>
>> Sorry for the delay in getting back to you, I had a busy week :(
>>
>> I'm still trying to work out how this all fits together, so can't comment on
>> what the best way to handle this is yet.
> 
> I've spent a bit more time looking at this and while I don't yet have
> any concrete
> suggestions, the way the link generation is being handled is certainly not
> optimal :( It seems pretty much all the POST data is getting included in some
> of the URLs generated after form submission.

Agree, this is quite a bad patch. I hadn't check all consequences...

I'll revert it.

> E.g. if you edit a record on a table, after submitting the form, in
> the "browse" view
> the table header links to sort columns also now contain all the data
> submitted from
> the form.

Exactly.

> I'll continue looking into it, it's useful to find out how things fit
> together anyway.

I'll try to revert this patch quickly, so we can work on a "clean" code.

Thank you for your help.

> 
> Regards
> 
> Ian Barwick

Re: [ppa-dev] Table action buttons not working after editing row

[Jehan-Guillaume (i. de R. <io...@fr...>]

On 09/02/2013 01:59, Ian Lawrence Barwick wrote:
> 2013/2/7 Jehan-Guillaume (ioguix) de Rorthais <io...@fr...>:
>> On 01/02/2013 12:07, Jehan-Guillaume (ioguix) de Rorthais wrote:
>>> On 01/02/2013 11:19, Ian Lawrence Barwick wrote:
>>>> Hi
>>>>
>>>> I was just poking about at this bytea problem with a sharp pointy
>>>> stick (no useful insights so far) and came across another issue,
>>>> namely after editing a row and clicking "save", the "edit" and
>>>> "action" buttons no longer work, and I see a bunch of these
>>>> errors:
>>>
>>> I just started to work on this bytea bug as well this morning and
>>> found this bug as well.
>>>
>>> As far as I could dig around this, I think the bug was introduced by
>>> this patch: e1a5b9c5 (git show e1a5b9c5).
>>>
>>> Enable plugin Report and mess around with it if you need to have a
>>> better understanding about what this patch tries to achieve.
>>>
>>>> "Notice: Array to string conversion in
>>>> /opt/www/localhost/htdocs/phppgadmin/classes/Misc.php on line
>>>> 1796"
>>>>
>>>> The "edit" link generated after saving the record does not work.
>>>
>>> yeah, confirmed.
>>>
>>>> This occurs in PHP 5.4.x using current git master.
>>>
>>> I don't think this bug is related to a specific PHP version.
>>>
>>>> It looks like the parameters from the POST request are being used
>>>> indiscriminately to populate the links, in display.php/
>>>> doBrowse(). The array errors are ugly but don't appear to be
>>>> critical; the actual problem seems to be that the generated link
>>>> contains "action=editrow", rather than what appears to be the
>>>> correct "action=confeditrow".
>>>>
>>>> I'm not entirely sure how the code fits together right now so
>>>> haven't got any patches. Possibly the links should be generated
>>>> using a whitelist to select the parameters to be used?
>>>
>>> Mh, the problem is that we don't know what parameters plugins will
>>> have to add, and I'm not sure we should add a specific API to allow
>>> them to register parameters to this whitelist.
>>>
>>> This part of the code need some more thoughts and refactoring, for sure:
>>>
>>> +               // Build array OF parameters for sorts/pages links
>>> +               $_gets = $_REQUEST;
>>> +               unset($_gets['query']);
>>> +               unset($_gets['MAX_FILE_SIZE']);
>>
>> I am considering to revert this patch to original code and find another
>> cleaner way to make the plugin Reports works correctly.
>>
>> Thoughts ?
> 
> Sorry for the delay in getting back to you, I had a busy week :(

No worries, we are pretty much all in this situation :)

> I'm still trying to work out how this all fits together, so can't comment on
> what the best way to handle this is yet.
> 
> BTW I've attached a very small patch to supress some "Undefined index"
> notices in the Report plugin.

Thanks, I'll review and push as soon as possible.

> Also, can I provide an "ABOUT" file or similar to include in the Report plugin
> source to give a brief explanation of what it does and how to use it? It
> wasn't immediately obvious to me.

Yup, please, proceed :)

> Regards
> 
> Ian Barwick

Re: [ppa-dev] Table action buttons not working after editing row

[Ian L. B. <ba...@gm...>]

2013/2/9 Ian Lawrence Barwick <ba...@gm...>:
> 2013/2/7 Jehan-Guillaume (ioguix) de Rorthais <io...@fr...>:
>> On 01/02/2013 12:07, Jehan-Guillaume (ioguix) de Rorthais wrote:
>>> On 01/02/2013 11:19, Ian Lawrence Barwick wrote:
(...)
>>>> It looks like the parameters from the POST request are being used
>>>> indiscriminately to populate the links, in display.php/
>>>> doBrowse(). The array errors are ugly but don't appear to be
>>>> critical; the actual problem seems to be that the generated link
>>>> contains "action=editrow", rather than what appears to be the
>>>> correct "action=confeditrow".
>>>>
>>>> I'm not entirely sure how the code fits together right now so
>>>> haven't got any patches. Possibly the links should be generated
>>>> using a whitelist to select the parameters to be used?
>>>
>>> Mh, the problem is that we don't know what parameters plugins will
>>> have to add, and I'm not sure we should add a specific API to allow
>>> them to register parameters to this whitelist.
>>>
>>> This part of the code need some more thoughts and refactoring, for sure:
>>>
>>> +               // Build array OF parameters for sorts/pages links
>>> +               $_gets = $_REQUEST;
>>> +               unset($_gets['query']);
>>> +               unset($_gets['MAX_FILE_SIZE']);
>>
>> I am considering to revert this patch to original code and find another
>> cleaner way to make the plugin Reports works correctly.
>>
>> Thoughts ?
>
> Sorry for the delay in getting back to you, I had a busy week :(
>
> I'm still trying to work out how this all fits together, so can't comment on
> what the best way to handle this is yet.

I've spent a bit more time looking at this and while I don't yet have
any concrete
suggestions, the way the link generation is being handled is certainly not
optimal :( It seems pretty much all the POST data is getting included in some
of the URLs generated after form submission.

E.g. if you edit a record on a table, after submitting the form, in
the "browse" view
the table header links to sort columns also now contain all the data
submitted from
the form.

I'll continue looking into it, it's useful to find out how things fit
together anyway.

Regards

Ian Barwick

Re: [ppa-dev] Table action buttons not working after editing row

[Ian L. B. <ba...@gm...>]

2013/2/7 Jehan-Guillaume (ioguix) de Rorthais <io...@fr...>:
> On 01/02/2013 12:07, Jehan-Guillaume (ioguix) de Rorthais wrote:
>> On 01/02/2013 11:19, Ian Lawrence Barwick wrote:
>>> Hi
>>>
>>> I was just poking about at this bytea problem with a sharp pointy
>>> stick (no useful insights so far) and came across another issue,
>>> namely after editing a row and clicking "save", the "edit" and
>>> "action" buttons no longer work, and I see a bunch of these
>>> errors:
>>
>> I just started to work on this bytea bug as well this morning and
>> found this bug as well.
>>
>> As far as I could dig around this, I think the bug was introduced by
>> this patch: e1a5b9c5 (git show e1a5b9c5).
>>
>> Enable plugin Report and mess around with it if you need to have a
>> better understanding about what this patch tries to achieve.
>>
>>> "Notice: Array to string conversion in
>>> /opt/www/localhost/htdocs/phppgadmin/classes/Misc.php on line
>>> 1796"
>>>
>>> The "edit" link generated after saving the record does not work.
>>
>> yeah, confirmed.
>>
>>> This occurs in PHP 5.4.x using current git master.
>>
>> I don't think this bug is related to a specific PHP version.
>>
>>> It looks like the parameters from the POST request are being used
>>> indiscriminately to populate the links, in display.php/
>>> doBrowse(). The array errors are ugly but don't appear to be
>>> critical; the actual problem seems to be that the generated link
>>> contains "action=editrow", rather than what appears to be the
>>> correct "action=confeditrow".
>>>
>>> I'm not entirely sure how the code fits together right now so
>>> haven't got any patches. Possibly the links should be generated
>>> using a whitelist to select the parameters to be used?
>>
>> Mh, the problem is that we don't know what parameters plugins will
>> have to add, and I'm not sure we should add a specific API to allow
>> them to register parameters to this whitelist.
>>
>> This part of the code need some more thoughts and refactoring, for sure:
>>
>> +               // Build array OF parameters for sorts/pages links
>> +               $_gets = $_REQUEST;
>> +               unset($_gets['query']);
>> +               unset($_gets['MAX_FILE_SIZE']);
>
> I am considering to revert this patch to original code and find another
> cleaner way to make the plugin Reports works correctly.
>
> Thoughts ?

Sorry for the delay in getting back to you, I had a busy week :(

I'm still trying to work out how this all fits together, so can't comment on
what the best way to handle this is yet.

BTW I've attached a very small patch to supress some "Undefined index"
notices in the Report plugin.

Also, can I provide an "ABOUT" file or similar to include in the Report plugin
source to give a brief explanation of what it does and how to use it? It
wasn't immediately obvious to me.

Regards

Ian Barwick

Re: [ppa-dev] Table action buttons not working after editing row

[Jehan-Guillaume (i. de R. <io...@fr...>]

On 01/02/2013 12:07, Jehan-Guillaume (ioguix) de Rorthais wrote:
> On 01/02/2013 11:19, Ian Lawrence Barwick wrote:
>> Hi
>>
>> I was just poking about at this bytea problem with a sharp pointy
>> stick (no useful insights so far) and came across another issue,
>> namely after editing a row and clicking "save", the "edit" and
>> "action" buttons no longer work, and I see a bunch of these
>> errors:
> 
> I just started to work on this bytea bug as well this morning and
> found this bug as well.
> 
> As far as I could dig around this, I think the bug was introduced by
> this patch: e1a5b9c5 (git show e1a5b9c5).
> 
> Enable plugin Report and mess around with it if you need to have a
> better understanding about what this patch tries to achieve.
> 
>> "Notice: Array to string conversion in 
>> /opt/www/localhost/htdocs/phppgadmin/classes/Misc.php on line
>> 1796"
>>
>> The "edit" link generated after saving the record does not work.
> 
> yeah, confirmed.
> 
>> This occurs in PHP 5.4.x using current git master.
> 
> I don't think this bug is related to a specific PHP version.
> 
>> It looks like the parameters from the POST request are being used 
>> indiscriminately to populate the links, in display.php/
>> doBrowse(). The array errors are ugly but don't appear to be
>> critical; the actual problem seems to be that the generated link
>> contains "action=editrow", rather than what appears to be the
>> correct "action=confeditrow".
>>
>> I'm not entirely sure how the code fits together right now so
>> haven't got any patches. Possibly the links should be generated
>> using a whitelist to select the parameters to be used?
> 
> Mh, the problem is that we don't know what parameters plugins will
> have to add, and I'm not sure we should add a specific API to allow
> them to register parameters to this whitelist.
> 
> This part of the code need some more thoughts and refactoring, for sure:
> 
> +               // Build array OF parameters for sorts/pages links
> +               $_gets = $_REQUEST;
> +               unset($_gets['query']);
> +               unset($_gets['MAX_FILE_SIZE']);

I am considering to revert this patch to original code and find another
cleaner way to make the plugin Reports works correctly.

Thoughts ?

> 
> This display.php and sql.php are total mess... :/
> 
> 
> As a side note, I'll be at Fosdem this week-end, not sure I'll be able
> to answer during next few days but I'll do my best...
> 
> Cheers,
> 
>> Regards
>>
>> Ian Barwick

Re: [ppa-dev] Table action buttons not working after editing row

[Jehan-Guillaume (i. de R. <io...@fr...>]

On 01/02/2013 11:19, Ian Lawrence Barwick wrote:
> Hi
> 
> I was just poking about at this bytea problem with a sharp pointy
> stick (no useful insights so far) and came across another issue,
> namely after editing a row and clicking "save", the "edit" and
> "action" buttons no longer work, and I see a bunch of these
> errors:

I just started to work on this bytea bug as well this morning and
found this bug as well.

As far as I could dig around this, I think the bug was introduced by
this patch: e1a5b9c5 (git show e1a5b9c5).

Enable plugin Report and mess around with it if you need to have a
better understanding about what this patch tries to achieve.

> "Notice: Array to string conversion in 
> /opt/www/localhost/htdocs/phppgadmin/classes/Misc.php on line
> 1796"
> 
> The "edit" link generated after saving the record does not work.

yeah, confirmed.

> This occurs in PHP 5.4.x using current git master.

I don't think this bug is related to a specific PHP version.

> It looks like the parameters from the POST request are being used 
> indiscriminately to populate the links, in display.php/
> doBrowse(). The array errors are ugly but don't appear to be
> critical; the actual problem seems to be that the generated link
> contains "action=editrow", rather than what appears to be the
> correct "action=confeditrow".
> 
> I'm not entirely sure how the code fits together right now so
> haven't got any patches. Possibly the links should be generated
> using a whitelist to select the parameters to be used?

Mh, the problem is that we don't know what parameters plugins will
have to add, and I'm not sure we should add a specific API to allow
them to register parameters to this whitelist.

This part of the code need some more thoughts and refactoring, for sure:

+               // Build array OF parameters for sorts/pages links
+               $_gets = $_REQUEST;
+               unset($_gets['query']);
+               unset($_gets['MAX_FILE_SIZE']);

This display.php and sql.php are total mess... :/


As a side note, I'll be at Fosdem this week-end, not sure I'll be able
to answer during next few days but I'll do my best...

Cheers,

> Regards
> 
> Ian Barwick

[ppa-dev] Table action buttons not working after editing row

[Ian L. B. <ba...@gm...>]

Hi

I was just poking about at this bytea problem with a sharp pointy stick
(no useful insights so far) and came across another issue, namely
after editing a row and clicking "save", the "edit" and "action" buttons
no longer work, and I see a bunch of these errors:

"Notice: Array to string conversion in
/opt/www/localhost/htdocs/phppgadmin/classes/Misc.php on line 1796"

The "edit" link generated after saving the record does not work.

This occurs in PHP 5.4.x using current git master.

It looks like the parameters from the POST request are being used
indiscriminately to populate the links, in display.php/ doBrowse().
The array errors are ugly but don't appear to be critical; the actual
problem seems to be that the generated link contains "action=editrow",
rather than what appears to be the correct "action=confeditrow".

I'm not entirely sure how the code fits together right now so haven't got any
patches. Possibly the links should be generated using a whitelist to
select the parameters to be used?


Regards

Ian Barwick

Re: [ppa-dev] Updates for the DEVELOPERS file

[Jehan-Guillaume (i. de R. <io...@fr...>]

On 01/02/2013 02:37, Ian Lawrence Barwick wrote:
> Hi
> 
> I couldn't help notice the DEVELOPERS file is chronically
> out-of-date and is speckled with references to some antediluvian
> technology called "CVS" ;) (This is one of the reasons why I wasn't
> sure of the current status of development).

heh :)

> Patch attached, please let me know if this is the correct
> procedure, etc.

Perfect, patch committed and pushed.

https://github.com/phppgadmin/phppgadmin/commit/a206766e1fe41a3b7b39fa27eaa6fa7966cf22a4

Thank you !

> Regards
> 
> Ian Barwick

[ppa-dev] Updates for the DEVELOPERS file

[Ian L. B. <ba...@gm...>]

Hi

I couldn't help notice the DEVELOPERS file is chronically out-of-date
and is speckled with references to some antediluvian technology
called "CVS" ;) (This is one of the reasons why I wasn't sure of the
current status of development).

Patch attached, please let me know if this is the correct procedure, etc.

Regards

Ian Barwick

Re: [ppa-dev] is phpPgAdmin development still active?

[Ian L. B. <ba...@gm...>]

2013/1/31 Jehan-Guillaume (ioguix) de Rorthais <io...@fr...>:
> On 31/01/2013 10:25, Ian Lawrence Barwick wrote:
>> 2013/1/30 Jehan-Guillaume (ioguix) de Rorthais <io...@fr...>:
>>>
>>> The official repository is :
>>>
>>> https://github.com/phppgadmin/phppgadmin/
>>
>> Slightly OT, more of a general GIT question: I have several
>> computers I use for development (Linux desktop, Macbook) and I'd
>> like to synchronise any development work I do between them. With
>> GIT, is it possible to clone the official repository to a private
>> server, and commit any changes I make locally to that clone to keep
>> my development computers in sync? And if so, how do I keep
>> everything in sync with the official repository?
>
> Even better, you can clone the phppgadmin repo on github and work on
> your own branch in your own repo and keep it in sync in your computers.
>
> When you think your patch is ready, you can either just make a pull
> request on github so we can merge it in the official repo quickly, or
> send your patch to the ml using "git format-patch" :)

Thanks, I think I've worked out how to set what I wanted. A small
(documentation) patch will follow shortly :)

Regards

Ian Barwick

Re: [ppa-dev] is phpPgAdmin development still active?

[Diorman C. <dex...@gm...>]

On Wed, Jan 30, 2013 at 8:56 PM, Robert Treat <ro...@xz...> wrote:

> On Wed, Jan 30, 2013 at 5:32 PM, Diorman Colmenares
> <dex...@gm...> wrote:
> > Hi guys,
> >
> > I don't think the split is a problem although for new people willing to
> get
> > involved could be just a bit confusing at first. In my opinion it would
> be
> > nice to have everything in the same place. It's up to you, though. I
> would
> > like to help but I just don't know where to start. I agree that creating
> a
> > todo list is one of things the project needs the most.
> >
>
> Heh, we actually have two TODO lists :-)
>

Good to know! I will give it a look in the near future. I thought there
wasn't any, sorry my bad. I just got a bit confused by this:

>> Is there an up-to-date todo list anywhere?
> Nope :/
> I guess we should start by this.



> The bug tracker:
>
> https://sourceforge.net/tracker/?limit=25&func=&group_id=37132&atid=418980&assignee=&status=&category=&artgroup=&keyword=&submitter=&artifact_id=&assignee=&status=1&category=&artgroup=&submitter=&keyword=&artifact_id=&submit=Filter&mass_category=&mass_priority=&mass_resolution=&mass_assignee=&mass_artgroup=&mass_status=&mass_cannedresponse=&_visit_cookie=c98015d9201bd0f0ed148da8094482bc
>
> (and btw, anything "assigned", feel free to claim if you want)
>
> And one in the code:
> https://github.com/phppgadmin/phppgadmin/blob/master/TODO
>
> Either one has things people can start hacking on, if they want.
>
>
> Robert Treat
> conjecture: xzilla.net
> consulting: omniti.com
>