glz_custom_fields

Logoleptic · 2007-12-10 20:59:45

iblastoff wrote:

i believe gerhard is working on escaping out of that limitation for the next major release of this plugin.

That would be outstanding!

variaas · 2007-12-10 21:13:30

good to know…thanks!

variaas · 2007-12-10 21:27:14

Can we look at adding portlet functionality?

Logoleptic · 2007-12-10 22:15:02

variaas wrote:

Can we look at adding portlet functionality?

Although giving developers and/or administrators (“Publisher” user level) the ability to move UI elements around the screen could be handy, I think it would only produce confusion for less advanced users. Besides, I’m not sure the kind of thing you linked to is even possible with the current markup structure of the Write tab.

Logoleptic · 2007-12-14 06:30:16

Bug Report: Because of the id attributes that it uses for replaced custom fields, glz_custom_fields is incompatible with any plugin that attempts to use the DOM method getElementById to single out custom fields on the Write tab.

In the glz_custom_fields_replace function, the plugin uses the custom field’s name for the id attribute of the on-page field. Textpattern, however, has a quirk in this department: it uses the field names with a hyphen instead of an underscore for this same attribute (e.g. custom-8 instead of custom_8). Other plugins that have been built with this in mind won’t work if glz_custom_fields is enabled.

Because other plugins assume that custom fields will be basic text inputs, you only need to fix this in the part of glz_custom_fields_replace that deals with that type of field.

This:

case "text_input":
  $custom_set_value = fInput("text", $custom_set, $custom_value, "edit", "", "", "22", "", $custom_set);
  break;

becomes this:

case "text_input":
  $custom_id = str_replace('_', '-', $custom_set);
  $custom_set_value = fInput("text", $custom_set, $custom_value, "edit", "", "", "22", "", $custom_id);
  break;

This fix has been tested to work on the installation that first demonstrated the bug for me (with upm_file_popper). I’d be interested in hearing if it works for others as well, without causing unforeseen problems.

My thanks to Gerhard for the awesome plugin. I hope this little patch is useful for him and others.

Logoleptic · 2007-12-30 21:08:36

I’d like to ask a favor of some glz_custom_field users. I just released a new custom field plugin that I originally developed for use in combination with Gerhard’s (though you can use it alone). I’ve never had a chance to test it on custom fields beyond 10, however, and I’m fresh out of time to set up a new test site for this purpose. Could someone give it a spin and let me know if this works? Thanks!

redbot · 2007-12-31 01:36:22

Adam,
very useful! Now I can use more than one checkbox for a single custom field (using delimiter=”|”).
For your question, I made a quick test and unfortunately it doesen’t seem to work with custom fields beyond 10. Anyway it works perfectly until 10.

Logoleptic · 2007-12-31 02:57:44

redbot wrote:

very useful! Now I can use more than one checkbox for a single custom field (using delimiter=”|”).

Keep in mind that you can’t count on the third checkbox in your group always being the third in the custom field’s value. Empty spots aren’t filled in when, for example, you check the third of three options. So instead of ||option3 you just get option3. It’d actually be nice to see that fixed, since it would make a conditional tag for checkboxes much easier to create (you could use mine, for example ;-).

For your question, I made a quick test and unfortunately it doesen’t seem to work with custom fields beyond 10. Anyway it works perfectly until 10.

That’s disappointing, but not too surprising. It has some similarities to the built-in <txp:custom_field /> tag, which also doesn’t work for 11 or more fields. Thanks for looking into it for me. :)

Can anyone tell me how the $thisarticle array gets populated? That seems to be the source of this particular problem, and if I knew how it works I might be able to figure out a work-around.

redbot · 2007-12-31 17:13:20

Logoleptic wrote

Keep in mind that you can’t count on the third checkbox in your group always being the third in the custom field’s value. Empty spots aren’t filled in when, for example, you check the third of three options. So instead of ||option3 you just get option3. It’d actually be nice to see that fixed, since it would make a conditional tag for checkboxes much easier to create (you could use mine, for example ;-).

Yes I know, I was thinking the same at first time, but I was wrong.
Actually – when using checkboxes – this should not be a problem at all: I can use conditional with no problem like this:

<txp:aam_if_scf name="colors" delimiter="|" val="blue">
do something
</txp:aam_if_scf>

If you think well about it you can see you never need to use the offset attribute ‘cause you never need to know the value of a single checkbox. You only need to know if it is checked or not so this is not a problem (I hope I was clear enough)
For you question about the $thisarticle array I cannot answer now cos I’m in a hurry. If I have some free time in next days I’ll let you know

Last edited by redbot (2007-12-31 17:20:31)

redbot · 2008-01-01 17:59:56

Logoleptic wrote

Can anyone tell me how the $thisarticle array gets populated? That seems to be the source of this particular problem, and if I knew how it works I might be able to figure out a work-around.

The $thisarticle array gets populated only with values untill custom field 10.
With version 1.0 there will be two new tags: glz_custom_field and glz_if_custom_field tags which can handle fields beyond 10 (see first post).
While v 1.0 comes out I’ve been using php to retrieve the contents of custom fields above 10:

<txp:php>
$id= $thisarticle['thisid'];
$custom_11_value = safe_field('custom_11', 'textpattern', "ID = $id");
echo $custom_11_value;
</txp:php>

I hope these informations can be of some use.

Logoleptic · 2008-01-02 02:03:37

redbot wrote:

If you think well about it you can see you never need to use the offset attribute ‘cause you never need to know the value of a single checkbox. You only need to know if it is checked or not so this is not a problem (I hope I was clear enough)

If offset is omitted from the conditional tag, it will default to 0. In your example, you’d only be comparing “blue” to the first item in the list. If the “blue” checkbox was the third in a set of three, and if “orange” was also checked, then the text in your example would never appear.

That said, you’ve inspired me to plan for some changes in the next release. It will become possible to test a specified value against every item in the list, not just a single selected value. With that change, the conditional tag will be usable in the way you described (for custom fields up to 10). Details are here, including an important forward-compatibility note. I hope to get this update released over the weekend.

I hope these informations can be of some use.

Yes, I think that will help. The way things look right now, though, Gerhard will probably release v1.0 before I get around to updating my plugin for the extra custom fields. I’m likely to be pretty busy for the next several weeks.

redbot · 2008-01-02 02:15:28

Oops, Sorry! In post #84 I was totally wrong though with the update you recently announced in the aam_split_custom_field thread it should work the way I intended. Thanks!

redbot · 2008-01-04 16:28:46

Oops sorry again Adam, I totally missed your latest post. I’m glad I (unintentionally) inspired a very useful change in the next release.
One last thing. You can make your plugin (and glz_custom_fields) work immediatly beyond custom field 10 with a little hack.
You simply have to change the 10 custom fields limit in function getCustomFields() in publish.php. given that the $thisarticle array retrieves custom fields names through this function.

visualpeople · 2008-01-11 19:30:52

Thanks redbot for your quick php fix for custom fields above 10 that will work great until 1.0 comes out.

I tried to change the custom fields limit in publish.php, but that didn’t seem to work…

Thanks again!

redbot · 2008-01-11 20:12:33

visualpeople wrote:

I tried to change the custom fields limit in publish.php, but that didn’t seem to work…

Strange. I confirm it works for me. To be clearer around line 1016 in publish.php I just replaced

for ($i=1; $i<=10; $i++) {

with

for ($i=1; $i<=20; $i++) {

Textpattern CMS

Textpattern CMS support forum

#76 2007-12-10 20:59:45

Re: glz_custom_fields

#77 2007-12-10 21:13:30

Re: glz_custom_fields

#78 2007-12-10 21:27:14

Re: glz_custom_fields

#79 2007-12-10 22:15:02

Re: glz_custom_fields

#80 2007-12-14 06:30:16

Re: glz_custom_fields

#81 2007-12-30 21:08:36

Re: glz_custom_fields

#82 2007-12-31 01:36:22

Re: glz_custom_fields

#83 2007-12-31 02:57:44

Re: glz_custom_fields

#84 2007-12-31 17:13:20

Re: glz_custom_fields

#85 2008-01-01 17:59:56

Re: glz_custom_fields

#86 2008-01-02 02:03:37

Re: glz_custom_fields

#87 2008-01-02 02:15:28

Re: glz_custom_fields

#88 2008-01-04 16:28:46

Re: glz_custom_fields

#89 2008-01-11 19:30:52

Re: glz_custom_fields

#90 2008-01-11 20:12:33

Re: glz_custom_fields

Board footer