glz_custom_fields

gerhard · 2009-03-09 09:31:18

mrdale wrote:

Yes, throw stuff in a library. Heck I don’t even mind two if you have to. This is far more modular

OO is modular, not separating stuff in multiple files/plugins etc. : ).

No, please don’t require a hacked version of TXP, this would mean be a nightmare for me to maintain. Other plugins that I use require emerging features of SVN builds. As it is, I regularly forget to apply the “custom fields hack”.

You need git mate. git & Capistrano. You cannot maintain 20+ websites that run on TXP (or any other CMS) without these 2 bad boys. I’l put together a screencast for that, within the next 2 weeks, promise!

To be perfectly honest I wish that we could talk the devs into rolling the functionality you’ve created for custom fields, in total, into the core. But failing that my ideal would be if the devs could give you the hooks you need in core so that we no longer require hacks, and those hooks by default don’t break anything existing

I will try approaching Robert & Ruud again, see if they had a change of heart since we last talked.

I’m sure ruby has it’s benefits but from my perspective, I’d have to learn to configure servers up for ruby and deal with all the related issues. I’d gladly do this if it meant that there were a whole host of clear benefits, but not simply to get the existing feature set.

Again, this is something you’ll have to discover for yourself but I’ve made the switch and I’ve never looked back. It’s a totally different game, honestly.

I really need a quiet mode for no results as I’m not really using this as a search mechanism, but as a way to pipe custom field information into forms. So an article list that redirects to a section or another page is, from the user’s perspective unexpected behavior.

You know you can include the search form on the search page as well and all the data that they have submitted will reflect in the search form (submitted values will be selected). Anyways, have a look at what I’ve mentioned 2 posts ago (in azw’s reply), see if that’s something you could warm up to.

Thanks guys, I couldn’t have done it without you!

Last edited by gerhard (2009-03-15 19:20:38)

mrdale · 2009-03-09 16:17:01

Crap I totally meant to reply to this and hit edit by accident. I’m trying to see if I can save it from cache somewhere.

Sorry, Sorry, sorry.

—Patrick

BTW, There’s someone else in my head… Patrick is a personality that arose to defend me from the trauma of hacking sites for IE

-Dale

Last edited by mrdale (2009-03-09 17:39:15)

maica · 2009-03-13 10:31:04

Hi there Gerhard. My compliments for glz_custom_fields. I have some questions about it and I hope this is the right place to ask them.

And let me warn you that I am no programmer so some questions may be silly, or maybe even all of them :S

glz_custom_fields does not combine nicely with sed_section_fields. I really don’t know which plugin is responsible for that. However, when I compare the generated sources of event=article-pages (1 page with glz_custom_fields active, the other with the plugin disabled), the page with the activated plugin shows that the id for any custom field is “custom-”. Might that have to do something with it?
is it possible to have the values of glz_custom_fields sorted by input-order (instead of alphabetical order)? That way I can decide for myself: if I want the values to appear alphabetically ordered, I add them that way, but if I want to have ‘very interesting’ above ‘averagely interesting’ (is ‘averagely’ an existing word? I am not English as you might have guessed), because chances are 9 in 10 the value is Very Interesting, for example.
is it absolutely necessary to have a search section created named search? If so, would it be possible to make a line somewhere at the top of the plugin where you can declare the name of the section used as search?

I think it’s a magnificent plugin, and when it would work with sed_custom_fields it would be even more so. I have 20 custom-fields in use now and for 1 section, I need the top 16 and for the rest of the sections, 1 & 17 to 20. It saves a lot of wrist-related matter- & energy-particles if unneeded custom fields would not have to be scrolled away, so to speak. And it looks much neater.

redbot · 2009-03-13 11:14:46

maica wrote:

glz_custom_fields does not combine nicely with sed_section_fields.

maica,
that’s strange, for me the two work well together. Maybe the problem is you are using more than 10 plugin? In this case have you applied this patch?.
If nothing of this works for you and you’re needing badly sed_section_fields features you can try this raw-but-working plugin made by me.

gerhard · 2009-03-15 19:20:09

maica wrote:

Hi there Gerhard. My compliments for glz_custom_fields. I have some questions about it and I hope this is the right place to ask them.

Hi Maica, thanks for the kind words! Yes, this is definitely the right place to ask for help. Even if I’m not always around, there are other great folks that can help out.

glz_custom_fields does not combine nicely with sed_section_fields.

I don’t really know why that is. I am still to try out the new glz_custom_fields with sed_section_fields and see if there are any inconsistencies.

is it possible to have the values of glz_custom_fields sorted by input-order

I’ve put this down for v1.2.1, don’t want to stall v1.2 anymore. You’re not the first one to have asked for this, so it’s definitely going to happen sooner rather than later.

is it absolutely necessary to have a search section created named search?

While I do agree that this might be a bit of an inconvenience, I just went with the most sensible convention. Looking back at it, it might not be the best, but I haven’t received a better suggestion. Because the search form is using POST, the /search part of the URL is the only indication for the user as to what is happening. Textpattern by default uses ?q=some_value and GET, but because of the arrays that glz_custom_fields_search_form generates, GET just seemed impractical.

I’m just trying to understand how using the search section to deal with searches affects your website(s) Maica.

Sending searches to the same page is something I am willing to explore as I’ve mentioned in my reply to Dale’s post, but I would like to understand what I’m overlooking.

azw · 2009-03-15 22:46:48

Hi, Gerhard,

Almost always, I send my php forms back to the very same page for processing. Often the display will change depending on what actions occur. In the old hand-coding days, sending the action back to the same page made for easier programming. I think it still makes a lot of sense with TXP. I’m doing it with my plugin.

garbo · 2009-04-01 00:30:25

I’m having something wonky going on with the custom fields and maybe you can help.

I designed a site for our church music group and I use glz_custom_fields to create tables of download links for music files, music sheets, musicians, etc. There are 32 custom fields in all. On all articles but two, all 32 fields show up on the Write page. The two other articles have only the first 10. However, the display on the actual site is not affected and all filled fields show up properly. I’m trying to figure out why just those two. Is there anything that can interfere with the plug-in? The custom fields are being filled by my client, so maybe he entered something that interferes with the plug-in? Bad or conflicting dates or some characters being parsed improperly inside the fields? I’m just guessing.

Any ideas what could be happening? I can provide more specific information if needed.

Thanks in advance.

azw · 2009-04-01 04:23:24

That is odd.

Are the two articles with problems in a different section than the other articles? Are they the most recent added or the first articles added? Is there anything else that sets these articles apart?

garbo · 2009-04-01 12:49:19

That’s what I’m trying to figure out. I can’t see what makes them different. All these articles are in the same section.

I thought it may be the publishing date which was identical in two cases, but when I change one, the problem persists. Both were supposed to be published March 22, but only one had the missing custom fields. The second article that had missing custom fields had no other conflict with another article. That one was to be published April 5.

These problem articles are in the middle, with articles published before, after and between.

Bizarre.

azw · 2009-04-01 17:30:24

Interesting. What I’d do next is compare the actual fields in the database using PhpMyAdmin.

garbo · 2009-04-02 16:54:23

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.

garbo · 2009-04-03 01:57:55

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.

azw · 2009-04-03 02:21:13

Great! Thanks, Gary, for reporting back on the solution.

gerhard · 2009-04-03 06:22:22

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.

azw · 2009-04-03 07:01:20

Hi, Gerhard,

For me, the screencast would be less important than the update.

Version 1.2 sounds like a big step forward!

Textpattern CMS

Textpattern CMS support forum

#256 2009-03-09 09:31:18

Re: glz_custom_fields

#257 2009-03-09 16:17:01

Re: glz_custom_fields

#258 2009-03-13 10:31:04

Re: glz_custom_fields

#259 2009-03-13 11:14:46

Re: glz_custom_fields

#260 2009-03-15 19:20:09

Re: glz_custom_fields

#261 2009-03-15 22:46:48

Re: glz_custom_fields

#262 2009-04-01 00:30:25

Re: glz_custom_fields

#263 2009-04-01 04:23:24

Re: glz_custom_fields

#264 2009-04-01 12:49:19

Re: glz_custom_fields

#265 2009-04-01 17:30:24

Re: glz_custom_fields

#266 2009-04-02 16:54:23

Re: glz_custom_fields

#267 2009-04-03 01:57:55

Re: glz_custom_fields

#268 2009-04-03 02:21:13

Re: glz_custom_fields

#269 2009-04-03 06:22:22

Re: glz_custom_fields

#270 2009-04-03 07:01:20

Re: glz_custom_fields

Board footer