glz_custom_fields

thermofunk · 2009-09-30 16:07:52

Hi Gerhard, I bought this plugin specially for the glz_custom_fields_search_form, now is not working and wet_haystack plugin is not solving my problem, it doesn’t work ok with Multi-Lingual Publishing Package. I need the dropdowns and checkboxes in the search form as I use to have, any suggestions about how to fix it? Many thanks, Martín.

jpdupont · 2009-09-30 16:41:40

John,

in the plugin code, line 1260, put this code {startDate:‘01/01/1996’} from your example :

$(".date-picker").datePicker({startDate:'01/01/1996'});

To put in the prefs, Gerhard ? With other settings like choice of language, if possible ???

johnstephens · 2009-09-30 19:42:45

Thanks, J.P. I applied the hack, and I verified by viewing source in the Write tab that the startDate was loading, but it still had past dates disabled.

This was because I had changed the date format to yyyy-mm-dd, as I mentioned above. Once I changed the startDate to use the same format, everything worked fine.

To Gerhard: If you develop a preferences UI to enable past date selected, keep in mind that the date format has to be consistent. Also, 1996 wasn’t early enough for my purpose— I set it to 1978. Thanks again, folks!

woof · 2009-09-30 23:42:38

Hi Gerhard, a question re Preferences.

In the Basic tab under Preferences I see 4 preferences under the heading glz_custom_f, the last of which is migrated and then in the Advanced tab under the heading Admin I see glz_custom_fields_migrated. Both have the value 1.
Is this duplication? If not what’s the difference between them please?

johnstephens · 2009-10-01 01:11:07

It would make a whole lot of sense to include date-picker prefs under the Add/Edit custom_x set when “Date Picker” is selected, rather than under the Basic site prefs. This would be consistent with the settings for other custom field types, and that’s the first place I looked— it wasn’t until delving into the plugin code that it dawned on me to check the site prefs.

If that was the case, you could have date pickers that used different formats for different custom fields, or different “starting dates” (allowing some to accept past data, and others to accept future dates). Could the javascript be written to target the specific element ids instead of .date-picker class?

Don’t mind me if all of this sounds too grandiose— this is an awesome plugin, and I trust in your vision for it’s development! Being able to customize the date-pickers further is very useful for me, but my cases might be toward the edge of the curve; I don’t know. ;)

jpdupont · 2009-10-02 16:33:41

John,
last days, before the release of 1.2.2 glz_custom_fields, I try to insert in my backend a datepicker on a custom field.

With bloke new admin theme plugin (and new txp theming !) : very easy.
Just edit the function html_head to insert the datepicker code.

I try first the jquery UI datepicker : works fine as you don’t modify the date format (I use yy-mm-dd).
So I try an other jQuery datepicker : http://keith-wood.name/datepick.html works here without any problem.

Maybe an alternative to gerhard choice ?

function html_head()
	{
       return '<link href="'.$this->url.'textpattern.css" rel="stylesheet" type="text/css" />'.n.
                  '<link type="text/css" href="/textpattern/js/datepicker/css/jquery.datepick.css" rel="stylesheet" />'.n.
                  '<script type="text/javascript" src="/textpattern/js/datepicker/js/jquery.datepick.js"></script>'.n.
	          '<script type="text/javascript" src="/textpattern/js/datepicker/js/jquery.datepick-fr.js"></script>'.n.
                  '<script type="text/javascript">'.n.
                        '$(document).ready(function() {'.n.
				'$("#custom-1").datepick({dateFormat: "yy-mm-dd", altField: "#custom-2", altFormat: "DD d MM yy"});'.n.
				'});'.n.
	          '</script>'.n;
}

whaleen · 2009-10-04 18:36:34

jstubbs wrote

Also see an error in the sidebar under “Advanced options” in the Write tab:
Notice: Undefined variable: custom_11_set in /users/home/me/domains/domain.com/web/public/v2/textpattern/include/txp_article.php on line 478
I had a custom_11 set defined but deleted it before installing the latest version of glz_.

gerhard responded

That might be related to max_custom_fields preference. If you have only 10 custom sets, make sure this variable value is also 10. This might also help explain what’s going on

gerhard had said previously

The bug occurs when there are unsequential custom sets. In talks with Robert, looking for a solution.

My experience: I am having the same problem as Jonathan. I set the max_custom_fields preference to ten, after which no error(s) like Jonathan’s occur. But then, when I add new fields in the glz_custom_fields extension tab the error(s) return. I say error(s) because for each field not in sequence above 10 returns an error. Furthermore adding custom_11 is not possible from the glz_custom_fields extension tab. Any other gaps in sequence above 10 will however be filled in with a new custom field creation.

I hope the you (Gerhard) and Robert don’t have to much trouble finding a solution.

One bug: When going to myssite.com/textpattern/index.php?event=plugin_prefs.glz_custom_fields I get “Restricted Access”. My TXP core is 4.2 and fresh and clean but the database was created a few versions ago. I don’t know if the state the database is in (some prefs?) can likely have an effect? I switched all plugins off to see if there was a conflict. There wasn’t.

edit: I admit to not knowing what tables had and now have all the custom field related data for vanilla txp and for glz-ified txp. If I did I might have had a solution.

Last edited by whaleen (2009-10-04 18:40:11)

kevinpotts · 2009-10-08 02:21:33

Boy I wish I had read the last few pages of this thread. Just deleted custom_5_set and now I’m served this error on the write page:

Notice: Undefined variable: custom_5_set in /my/site/domain.com/textpattern/include/txp_article.php on line 478

Any news on a patch?

And keep up the great work. This plugin is as essential as zem_contact_reborn.

Update: This is suddenly a very big deal. Because of this, I cannot publish any new articles. Going into phpMyAdmin to see what else I can break.

Update #2: Well I dove into phpMyAdmin just to confirm custom_5 was deleted from the textpattern table, and it was. I recreated it. I can now publish and save new articles, but I am still getting the error above, and custom_5_set does not appear at all in the admin screen for glz_custom_fields. However, considering I know zilch about MySQL, any fiddling I do in phpMyAdmin that does not directly result in melting the core of the entire interweb a minor victory.

Last edited by kevinpotts (2009-10-08 02:50:51)

decoderltd · 2009-10-08 09:46:15

Hi Kevin,

I found that creating a new custom field (from within glz_custom_fields) for the deleted location got rid of that warning.

Last edited by decoderltd (2009-10-08 09:47:41)

kevinpotts · 2009-10-08 12:48:43

@decoderltd — That seems to have worked. It threw me an initial duplicate column error, but after I clicked away, all errors seem to be gone and all is right with the world. Thanks!

Last edited by kevinpotts (2009-10-08 12:49:10)

mrdale · 2009-10-08 14:10:06

gerhard, can we twist your arm while we have your attention-ish to do another rev of glz with some of the simpler feature requests and bug squashies?

gerhard · 2009-10-09 12:28:38

mrdale wrote:

gerhard, can we twist your arm while we have your attention-ish to do another rev of glz with some of the simpler feature requests and bug squashies?

Hi Dale, I was planning a release this week, might need to wait until the next one though.

I have taken note of all the bugs that you’ve mentioned here and have addressed most of them, the most serious one has to do with deleting sequential custom sets. I’ve just sent an e-mail to Robert with a proposed solution, this is the gist of it.

In glz_custom_fields v1.2.2 I am no longer making a difference between 1-10 custom sets and the ones above that (e.g. custom_11_set, custom_12_set etc.). Since a user can adjust a custom set positioning, it makes no relevance whether that’s custom_5_set or custom_50_set. If custom_6_set is deleted, there will be an error because we’re using max_custom_fields to iterate over custom sets, when $i = 6, custom_6_set won’t be found . With my suggested changes, we could simply iterate over $prefs['custom']. This is what I’m proposing

This is an important change because this will open the floodgates for custom fields for other data types which I would like to see in the plugin before the end of this year : ).

Textpattern CMS

Textpattern CMS support forum

#517 2009-09-30 16:07:52

Re: glz_custom_fields

#518 2009-09-30 16:41:40

Re: glz_custom_fields

#519 2009-09-30 19:42:45

Re: glz_custom_fields

#520 2009-09-30 23:42:38

Re: glz_custom_fields

#521 2009-10-01 01:11:07

Re: glz_custom_fields

#522 2009-10-02 16:33:41

Re: glz_custom_fields

#523 2009-10-04 18:36:34

Re: glz_custom_fields

#524 2009-10-08 02:21:33

Re: glz_custom_fields

#525 2009-10-08 09:46:15

Re: glz_custom_fields

#526 2009-10-08 12:48:43

Re: glz_custom_fields

#527 2009-10-08 14:10:06

Re: glz_custom_fields

#528 2009-10-09 12:28:38

Re: glz_custom_fields

Board footer