glz_custom_fields

gerhard · 2009-03-09 07:20:24

redbot wrote:

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.

If the plugin goes over the size that TXP creators initially considered to be more than enough, I think that is a problem. Also, this is no ordinary plugin because it changes a lot of the core functionality – retrieving articles, populating the returning result with various data etc. So while a lib would be better to offload some of the “helper functions”, a proper OO approach would make it more flexible and easier to update specific parts. The alternative would be to drop PHP4 support and do it a PHP5 only, make use of the bare minimum OO that PHP provides.

Also, I must start using a test suite, I feel all naked and embarased without one! I’m thinking SimpleTest. Any other suggestions?

redbot wrote:

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

Done

redbot wrote:

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).

If you only knew what you’re missing on, I’m sure you would have a change of heart. But you’re right, whatever suits you better guys. As I was mentioning in another post, this plugin is the only reason for which I still code PHP. Keeping old habits around might prove useful one day : ).

redbot wrote:

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.

I know, I wish the same, that would make things so much more easier!

gerhard · 2009-03-09 07:41:44

azw wrote:

I like the library plugin idea more than the replacement or patching of a TXP file.

I’m 100% you haven’t had a look at my changes to TXP 4.0.8. It doesn’t matter whether the plugin is there or not, they just bring custom fields > 10 support, better article searching for custom fields with multiple values and better defaults (like the config.php).

Also, you’re not using git and Capistrano, right? I will put together a Textpattern on git tutorial just for you, I know for a fact that you will never look back.

azw wrote:

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

I have asked, not much luck there..

azw wrote:

Although I have great interest in Ruby on Rails, I won’t have the time to learn it in the near future… y web hosts (who are very good) don’t support Ruby on Rails…

I know, old habits die hard. If you do join the Ruby folk and discover Procs, rspec and gems, think of me, ok? : )

azw wrote:

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”?

The reason why I’m sending all search requests to the search section is because the new search in glz_custom_fields v1.2 is more like an advanced search. You now can search by section & category at the same time as for custom fields. Imagine you have an e-commerce website with products in various categories. It makes perfect sense to search by price range (custom field) and category.

I will think about making this configurable so that you can send search requests either to the same page or to the search section.

azw wrote:

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!

Yes, I have played with that option, but the tag for the search form currently looks like this:

<glz_custom_fields_search_form searchby="custom_field_1, custom_field_2:radio, section, category" section="all" category="all" />

custom_field_1 will generate a form element based on the type of that custom field (if it’s a select, it will be a select in the search form etc.) and it will populate it with values from all the live articles
custom_field_2:radio will generate a radio input (this gets forced by the :radio declaration) with values from all the live articles
section will generate checkboxes (this cannot be overriden) with all searchable sections
category same as above but for categories
section="all" is going to look in all searchable sections if the visitor doesn’t select a section checkbox
category="all" is going to look in all searchable sections if the visitor doesn’t select a section checkbox

I have tried doing something like custom_field_1:exact, but that was a bit ugly for custom_field_2:radio:exact. Maybe what I’m after is another attribute, something like match="exact|approx". Hmmm, will get back to you after I try this one out.

gerhard · 2009-03-09 07:42:28

@mrdale, will get back to you as well, must run now!

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.

Textpattern CMS

Textpattern CMS support forum

#253 2009-03-09 07:20:24

Re: glz_custom_fields

#254 2009-03-09 07:41:44

Re: glz_custom_fields

#255 2009-03-09 07:42:28

Re: glz_custom_fields

#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

Board footer