glz_custom_fields

azw · 2009-02-01 08:15:23

Thanks, Gary! That’s god to know.

bmsorg · 2009-02-25 19:02:55

Excited to utilize this plugin… thanks for your help Art.

Last edited by bmsorg (2009-02-25 20:32:38)

gerhard · 2009-03-08 09:32:46

I will try to answer as many of your posts as I can, I know there has been a lot of activity since I’ve last been here.

Gary Horsman – garbo mentioned about the patch that you have to apply to the newer TXP builds (4.0.7 and 4.0.8) for the plugin to work. I will give you the background to this.

Initially I was duplicating a lot of the core TXP functions in my plugin. article became glz_article, custom_field became glz_custom_field etc. I thought this will work just fine, but then the plugin went over the 64k limit that a MySQL TEXT column type supports. Modifying it to LONGTEXT just didn’t seem right, just as maintaining all the duplicated functions started to become more and more difficult.

So now we have a patched version of Textpattern which also includes a few minor modifications that I consider to be useful. You can see what changes I’ve added by hovering over the red dots on the txp-gerhard branch, click on them to view the diffs. I haven’t finalized the TXP 4.0.8 patch for glz_custom_fields v1.2, I will make it available separately if you want to apply it manually on TXP 4.0.8.

When you are going to install glz_custom_fields v1.2, use the above patched version of TXP, it’s easy, pain free and guaranteed to work : ). I will create a few screencasts (with sound this time) to demo the various methods of setting up glz_custom_fields with TXP.

gerhard · 2009-03-08 09:35:53

abacabb wrote:

It appears when I use it in a code block, it will partially work, but it won’t exclude everything inside the tag, just the part that pertains to the actual call to glz_custom_field.

The newest glz_custom_fields v1.2 should have this fixed since it’s no longer duplicating core TXP functions, but patching them instead. Have a look at this post and please PM or e-mail if you want to try out the new beta before v1.2 stable is released.

gerhard · 2009-03-08 10:42:58

azw wrote:

There are several issues with the plugin. It has some problems with it’s built-in search function. In particular, if someone does a search and it doesn’t find anything, it takes you to a different section, a miserable solution.

In the new v1.2, all searches are directed to the search section (automatically created at plugin install if the section doesn’t exist). The patched version of TXP, automatically picks up custom fields and it formats them correctly for the search.

The problem that I’m having at the minute – and you guys can come up with a suggestion, I’m not entirely sure how to search for custom_field values. For example, if I use a MySQL LIKE with %, if you look for a price that is 100, it will also include 1009, 100500 etc. I could add options through checkboxes like “exact match”, but this will complicate the search form a lot. What are your thoughts?

gerhard · 2009-03-08 11:10:51

masa wrote:

Trigger Words are a planned feature for version 1.3. We’re currently at 1.1.3 and this plugin hasn’t seen any update for a while.
I wonder if Gerhard is still working on it?

Hi masa, I’m still working on the plugin but progress is made very slowly because of all my other commitments. We already have v1.2 beta, I’m just finishing off the search functionality – I asked for some input in regards to this btw – and then I’m ready to share the stable version. Beta was given only to a few people to test and provide me with feedback so that I could consolidate before making it public.

Your concern is very valid though, I have been thinking about the future of glz_custom_fields. There is a point where a plugin becomes much more than that, and I believe glz_custom_fields has reached this point. Even to start with, it took such a long time for someone to make this functionality available to Textpattern because of the inherent complexity. It took a lot of time and tinkering to come with the solution in the first place, now that it’s out there, ensuring it’s growth is the new challenge. I mean, adding new features to it is a bit of a pain because of the sheer size. There is a lot of duplication in glz_custom_fields that a lot of TXP plugin coders address through lib plugins – plugins that have the sole focus of providing core functions to other plugins, usually by the same author. glz_custom_fields is the only real TXP plugin that I maintain. If I was knocking TXP plugins front, left and right it would be justified, but it isn’t just for 1 plugin.

The bottom line is that without proper encapsulation provided by classes & modules, tests (almost every programming language is so far behind Ruby & Rails when it comes to testing) and tools such as git, the future of glz_custom_fields doesn’t look very good. Things can progress in the same fashion, but development will be slow (everyone hates that, including me), new functionality will introduce bugs which will increase in a DP relationship to the codebase.

I had enough time to think about this, and with my current knowledge, rewriting TXP in Ruby seems the best option. I know this deserves a different topic, but glz_custom_fields has given you just a glimpse of what’s possible. I don’t think it even counts as the tip of the iceberg – maybe the reflection of the iceberg’s tip : ).

What is your gut feeling guys? Do you think there is enough interest and community support for something like this?

Last edited by gerhard (2009-03-08 11:13:44)

gerhard · 2009-03-08 11:14:10

Timid&friendly wrote:

I see TRIGGER WORDS have been added e.g. |Image Categories| (select with all existing image categories)

Just as masa pointed out, this is a planned feature for v1.3. I cannot guarantee that there will be a v1.3 though, I am in a bit of dilemma right now, could do with your opinion : ).

gerhard · 2009-03-08 11:39:48

coopersita wrote:

I have a field called “Price” where a number is entered (eg. “12.00”), and I want to show it as ranges in the search dropdown (eg. $0-$4.99, $5-$9.99, etc.), instead of a list of prices that have been entered (eg, “4.00, 12.99, 14.25, etc.). How do I do that?

azw’s instructions regarding ranges are very accurate. Sorry for making the help so cryptic, maybe someone would like to rephrase it so that it makes more sense. I’m going to paste what we have currently:

Tricks

Actually, there is a single one, but I’ll let you know if I’ll implement more ; ).

If you want to define ranges, create a new custom field with the following name e.g. Price range &pound;(after)

range – this is really important and must be present for the range to work correctly
&pound; – don’t use straight symbols (like € or £) but entity ones e.g. &pound; & &euro; $ and &cent are valid symbols.
(after) – don’t leave any spaces after e.g. $ and (after). This basically says where to add the measuring unit (be it a currency or something like m<sup>3</sup> etc.) – (before) is default.

The reason for implementing ranges the way I did is because they have relevance for searching more than viewing individual articles. For example, someone would be more inclined to search for a price range, size range etc. rather than a specific value. When it comes to displaying that specific article (be it a house, product etc.), you want to see the exact price, not the range. So when it comes to ranges, they would come as an addition to an already existing custom field that defines a price, size etc.

In your case coopersita, you would have a Price custom field and a Price range $. By default (and this is specified in the help), the measuring unit ($ in your case) would appear before the price(e.g. $10.49). If you wanted it to appear after, you would have to define this explicitly, therefore the name of your range custom field would become Price range $(after).

Hope the above makes sense to everyone looking for help with how ranges work in glz_custom_fields. If not, please submit your additions to the help pasted above and I’ll look into implementing them in the plugin help.

coopersita wrote:

I also get a 200 error when there is no search results… People have to click in the link to be redirected.

This has already been addressed, v1.2 had the whole search functionality re-written.

redbot · 2009-03-08 16:00:46

Hi Gerhard,
glad to see you back and happy to hear about the new version,

some thoughts:

Using lib plugins: frankly I don’t see any problem in using them even if for just one plugin. I think I’ve seen other ‘unique’ plugins that need a library. What I mean is that plugins size shouldn’t be considered as a big problem IMHO.

Check for Jquery: given that v 1.2 is still a beta, can’t you take care of the problem outlinead here?

Rewriting TXP in Ruby: I’m sure this will rise a great interest, but I know nothing about Ruby on Rails and for sure I won’t be learning it in the near future so I think I’ll stick with the ‘classic’ textpattern and I wish this fundamental plugin will still have a future in txp (php version).

Txp hacks This is only a wish: I hope the native 10 custom fiels limit will be sometime addressed in the official txp version so we will need no more hacks and all this ‘functions duplication’ …and your plugin could be a lot more smaller and maintanable.

azw · 2009-03-08 16:49:36

Hi, Gerhard,

I agree with Redbot on several points.

I like the library plugin idea more than the replacement or patching of a TXP file. Plugins make tge installation and removal of a plugin in very easy.

Another approach might be to get some of the necessary changes included in the TXP core. Would that be possible?

Although I have great interest in Ruby on Rails, I won’t have the time to learn it in the near future, so that would make it impossible for me to begin using it with TXP. If I remember correctly, my web hosts (who are very good) don’t support Ruby on Rails, so that’s another impediment to moving over.

Finally on search, there are two issues.

First, going to a different page doesn’t meet my needs because I like to take users back to the same form so they can try again. Having them click to return is awkward in terms of usability and adds an extra click. It’s also possible that I would have several search functions in one site, so a search section would have to be generic, which is also more difficult. Is there any reason why a search with no results couldn’t return to the sending page with a simple text message “no results found”?

Your question about the %LIKE and EXACT searches is a good one. It may be good to have a default and to allow us to add one attribute to the search tag (like or exact) so that we could control it when we write the tag. That would reduce complexity for the user, but allow us the option to use either. I like that idea a lot!

Thanks for all your good work on this plugin, Gerhard!

redbot · 2009-03-08 17:10:50

azw wrote:

Another approach might be to get some of the necessary changes included in the TXP core. Would that be possible?

Hi azw, I can’t find it now but I remember I already asked for this in the past and unfortunately the proposal was rejected – I don’t remember why though…

mrdale · 2009-03-08 17:29:00

Welcome Back Gerhard,

Thanks for a great plugin that makes all kinds of new stuff possible in TXP. I use it on almost all of my sites, (20ish). Maintaining these installs is a constant juggling act, which prompts me to share my wish list for your plugin.

Yes, throw stuff in a library. Heck I don’t even mind two if you have to. This is far more modular
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”.
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’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.
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.

Anyway, hope this helps. Thanks again for a truly remarkable plugin.

Textpattern CMS

Textpattern CMS support forum

#241 2009-02-01 08:15:23

Re: glz_custom_fields

#242 2009-02-25 19:02:55

Re: glz_custom_fields

#243 2009-03-08 09:32:46

Re: glz_custom_fields

#244 2009-03-08 09:35:53

Re: glz_custom_fields

#245 2009-03-08 10:42:58

Re: glz_custom_fields

#246 2009-03-08 11:10:51

Re: glz_custom_fields

#247 2009-03-08 11:14:10

Re: glz_custom_fields

#248 2009-03-08 11:39:48

Re: glz_custom_fields

Tricks

#249 2009-03-08 16:00:46

Re: glz_custom_fields

#250 2009-03-08 16:49:36

Re: glz_custom_fields

#251 2009-03-08 17:10:50

Re: glz_custom_fields

#252 2009-03-08 17:29:00

Re: glz_custom_fields

Board footer