Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
#265 2009-04-01 17:30:24
- azw
- Member
- Registered: 2007-01-29
- Posts: 279
Re: glz_custom_fields
Interesting. What I’d do next is compare the actual fields in the database using PhpMyAdmin.
Offline
#266 2009-04-02 16:54:23
Re: glz_custom_fields
I checked out the fields in Sequel Pro and there’s nothing distinctive about them that would seem to make them behave any differently than any of the other articles.
Offline
#267 2009-04-03 01:57:55
Re: glz_custom_fields
We found the problem.
It seems that if you type an apostrophe in one of the custom fields, it messes up the plug-in by trying to parse the contents. The solution is to use unicode in place of the apostrophe like ’ or ’. Escaping using a backslash doesn’t work, though.
Well, I guess that’s PHP for you, sometimes. Typos seem to be the problem 90% of the time when something goes haywire. But I am surprised that the plug-in doesn’t take that into account, especially in textfields.
Offline
#268 2009-04-03 02:21:13
- azw
- Member
- Registered: 2007-01-29
- Posts: 279
Re: glz_custom_fields
Great! Thanks, Gary, for reporting back on the solution.
Offline
#269 2009-04-03 06:22:22
Re: glz_custom_fields
Hey Gary, thank you very much for figuring this one out!
The new, v1.2 does take into account non-alphanumeric characters and escapes them nicely therefore limiting all sorts of “bugs” that a “ ‘ ` can create. You are saying that escaping with a backslash does not work, but I’m wondering if all the other changes that I’ve made are effective in your situation. How can I reproduce your issue?
Even though the new version has been on my mind every day, I still didn’t have time to wrap it up. Just as I was demoing it in the new screencast, I came across a bug in the search form that’s proving a bit of a challenge. I’m just wondering if I should fix it, package it and distribute it, while finishing the screencast at another time. I am aware that I’ve been keeping you forever, and I can’t say that I’m happy about it.
Offline
#270 2009-04-03 07:01:20
- azw
- Member
- Registered: 2007-01-29
- Posts: 279
Re: glz_custom_fields
Hi, Gerhard,
For me, the screencast would be less important than the update.
Version 1.2 sounds like a big step forward!
Offline
#271 2009-04-03 08:12:15
Offline
#272 2009-04-03 15:00:55
Re: glz_custom_fields
Thanks for the responses, Gerard and AZW. If you’d like to reproduce the issue, you should set up a group of about twenty or so custom fields for a site (I set up 32 in my case), fill them up with text, and then try to enter text containing an apostrophe into one of them, such as: I’m Title One. In my client’s case, all fields numbered 11 and above disappeared from the write tab, but they remained present in the database and displayed on the site. Then try to use the HTML entity for an apostrophe instead. It works with the entity. At my suggestion, he also tried using a backslash before the apostrophe, but both the backslash and apostrophe displayed on the web page. Funny.
Yes. The sooner 1.2 can get out the door, the better. This is an indispensable plug-in, so I do look forward to the next update.
Offline
#273 2009-04-15 08:04:44
- mlarino
- Member
- Registered: 2007-06-29
- Posts: 367
Re: glz_custom_fields
Looking forward to the next update also, defenetly will need to use it in any website I create.
Specially because the one out now only works for txp 4.0.6 :(
Offline
#274 2009-04-15 15:50:32
Re: glz_custom_fields
gerhard> I’m still not clear on what hacks to a vanilla TXP install the latest version of glz will require.
Offline
#275 2009-04-15 16:05:52
- redbot
- Plugin Author
- Registered: 2006-02-14
- Posts: 1,410
Re: glz_custom_fields
mrdale wrote:
gerhard> I’m still not clear on what hacks to a vanilla TXP install the latest version of glz will require.
Happy to hear I’m not the only one.
Offline
#276 2009-04-16 08:50:07
Re: glz_custom_fields
Hey guys, I had an e-mail exchange with one of the glz_custom_fields contributors, I’m pasting it here since I think it’s going to be useful:
I don’t think they will merge it [my TXP changes] back into the main TXP distribution. This is going to happen sooner than seeing my patches in TXP. Maybe the core developers are so reluctant to merge the changes because some of them are very specific to my plugin. They would basically have to tweak TXP so that my plugin works with article, article_custom etc. I don’t remember them doing this for any other plugin, no reason to start with mine.
The original approach was to duplicate all the article functions such as article(), article_custom(), doArticle(), doArticles() etc. This proved so difficult to maintain that it wasn’t worth it. Whenever something changes in those functions, it’s like finding needles (because it’s not only one) in a haystack. Even a diff isn’t too helpful. Also, there is the glz_custom_fields_search_form which also needs changes to buildCustomSql() and extra tweaks to doArticles().
And, if this wasn’t enough, with v1.2, all those changes made the plugin go past the 64k limit that a SQL TEXT column supports. If I would have duplicated all the functions required for glz_custom_fields, people would have to change the db column type to LONGTEXT, or otherwise the plugin couldn’t be loaded. The other alternative was to separate the plugin in a glz_custom_fields and glz_custom_fields_lib, but that seemed more hassle. I mean, people still need to apply a patch (even in my original version of the plugin), so why jump through all those hoops when that extra step of patching was there since the very beginning?
This is the most recent diff between TXP v4.0.8 & txp-gerhard. There are a few more differences, but they have to do with indentation (editor has replaced some tabs for hard spaces). There will be a few more by the time I finish implementing the search functionality which is currently proving a bit tricky. Most of the issues have to do with how MySQL parser escapes characters (e.g. double escape in LIKE functions) & processing POST arrays when searching for custom fields.
Offline