gyrus / wordpress-developers-custom-fields Goto Github PK

Hello,

I'm new to theme development and would like to know if there was a way to integrate this plugin into the theme installation and then hide it.

Is there a settings.php file which you can import setting into which will set these custom fields up?

It would be nice to be able to edit a file's title, alt text, etc. after uploading via a 'file' field type, without leaving the modal dialog.

The map should zoom to the location suggested by the geocode autocomplete listing if the geocoder returns a zoom level.

On my Windows machines, with clean installs of WordPress, Google Map fields seem to be outputting strangely. There are slight "ruptures" in the map, and the top-left controls are visually broken, almost unusable.

This is only on the front-end - in the admin display is perfect.

Other developers have not been able to replicate this. Please let me know if you can!

Putting the discussion here in case anyone finds it of interest...

Currently wysiwyg fields have the filters wp_kses_post (potentially) and wpautop (always) applied before saving to the database. This means that the field content has <p> and </p> tags, which are added by TinyMCE, saved into the database field itself. This is unlike standard post content wysiwyg fields, which have <p> and </p> tags stripped before being saved to the database, and then added again on output by the the_content filter.

The fact that DCF doesn't apply the_content to wysiwyg output means that shortcodes aren't converted. Additionally, if the_content is applied to the output, shortcode are converted but oembeds are not. This is because the oembed regexp looks for an oembed URL directly preceded by a carriage return, whereas the field output contains lines that start with <p> tags, e.g. <p>http://www.youtube.com/...

The idea is to strip <p> and </p> tags when saving the field and to apply the_content to the output, which will automatically enabled shortcodes and oembeds. This would also enable the use of things like the Gravity Forms button which is also displayed alongside the Add Media button with the media_buttons setting in wysiwyg_options.

[As a side note, the "Add Media" button above wysiwyg fields works as expected as it just adds the HTML tags for that image.]

the_content applies the following filters as far as I can see...

wptexturize - http://codex.wordpress.org/Function_Reference/wptexturize
convert_smilies - http://codex.wordpress.org/Function_Reference/convert_smilies
convert_chars - http://codex.wordpress.org/Function_Reference/convert_chars
wpautop - http://codex.wordpress.org/Function_Reference/wpautop
shortcode_unautop - http://wpseek.com/shortcode_unautop/
prepend_attachment - http://wpseek.com/prepend_attachment/
capital_P_dangit - http://codex.wordpress.org/Function_Reference/capital_P_dangit
do_shortcode - http://codex.wordpress.org/Function_Reference/do_shortcode

... and also does the oembeds.

It looks like the_content therefore doesn't do much of significance in terms of backwards compatibility, although there will of course be other plugins which hook into that filter to do extra filtering.

The main question seems to be whether this should be default behaviour, or whether this behaviour should have to be turned on explicitly. The fact that the_content doesn't do a great deal, and the built-in post content field has this applied by default, would argue for it to be default behaviour. I suppose there may be cases of unexpected behaviour when used with other plugins, but if the plugin currently doesn't convert shortcodes or oembed URLs, then those won't be included in anyone's existing DCF wysiwyg content fields anyway. I would argue the same is likely to be true of other plugins in the vast majority of cases.

The database fields for wysiwyg content will have <p> and </p> tags in them. When the_content is applied to fields like this, these tags are processed without any issue, so there are no conflicts with existing stored fields as far as I can see.

Therefore, my conclusion would be to strip <p> and </p> tags when saving wysiwyg fields and apply the_content to the output. Any other opinions?

Hello.
I use Google Maps field. When I'm setting a marker on a Google Map, I input its address - Street, City etc. into form field. How can I use its address further - could I get the address into some variable?

Best regards.

Using version 0.7.2.1 on a fresh WordPress 3.3 installation.

When registering a Box using "type"=>"user" and defining field scope to "Subscribers" as such:

"scope"=>array("subscriber")

The custom field is only viewable/editable by Administrators. Is this the intent of the plugin, or is there a scope issue? I also tried leaving the scope parameter off, as the default should be "All" as per the documentation, but in such a case, still only Administrators can see or edit the fields.

Thanks.

Hi,

I am using slt-custom-fields. And, i found that in radio it is using array key as radio button label and array value as radio button value.
Please see the below attached screenshots.
http://awesomescreenshot.com/0a3ct1jc5
http://awesomescreenshot.com/0c7ct1rea
http://awesomescreenshot.com/06fct2s69

The slt_cf_field_value() function does not appear to output the default values of static field types when used with Wordpress 3.5 "attachment" post types. For example, suppose a custom field is configured with type of "select", static options of "Not applicable", "Yes", and "No", the default value set to "Not applicable", and the multiple parameter set to "false". After registering the custom fields and while editing an attachment in Wordpress, if the user does not select a value from the box (in other words leaving the select box set to the default value), that default value will not be output via the slt_cf_field_value() function. In order to successfully output the default value, the post must be edited by selecting a value other than the default, saved, then edited again to select the default value. Saving the post then outputs the default value via slt_cf_field_value() as expected.

Selections of values other than the default are output as expected.

The array of options created by options_query (i.e. posts, users, or taxonomy terms) is set up so the keys are the labels and the values are the IDs. This is so the value in the array maps to the value for the option tag in select drop-downs.

However, if there happen to be posts with identical titles (or users with identical names), only the last one from the query will survive into the final output.

Reversing the keys and values, so the keys are IDs, could be tricky because when options_type is set to static, it uses the same format - and the change would break all sites where there are hard-coded static options.

We could either:

• Reverse the keys and values only for the options_query-based arrays (and deal with them differently for output); or
• Append IDs to the labels for items with duplicates

It looks like there's a bug with the new multiple markers code. slt_cf_gmap() was defaulting $location_markers to (int) $location_markers, which would translate null to 0 if no parameters are passed. However, you can (or should be able to) call slt_cf_gmap() with no parameters to default to the stored data for the post. So the $map_markers array gets set up, but $location_markers is zero, so nothing gets output.

I think this is a better way of defaulting $location_markers, after $values is set up with the map markers data:

a44f905

Hello,
First many thank's for your code. I've got more a user question than an issue :

Do you know if i can use WPDCF to store historical values for one field (ie like a stock price or a historic weather datatable) ?

Many thanks

B.

Oops, this is a duplicate of this issue: #18

New posts with a google map field are displaying a map with the pointer on Glasgow(!), when the radio button is set to 'no'.

If I add a location, save the page and remove the location again, the map disappears.

I have custom post type but we want to show different layout/design for child pages. We use get_template_part() to pull different template parts. Is it possible to get slt_cf work with this?

For example, when I say get_template_part('product', 'single'), the wordpress will look for template called product-single.php, i fit finds it, it uses it. Will slt_cf identify this as a template or what would be possible solution?...

Thanks so much

Perhaps this should be an option, on by default. It would prevent the deletion of media items when they are associated via a custom field to a post or user.

Alternatively, those associations could be removed (with a confirmation) when the media item is deleted.

Hi Gyrus, wow, DCF is a great project! I would love to use it togethter with my plugin "Inline Attachments", but it's causing a javascript error:

parent.document.getElementById("TB_iframeContent") is null

Obviously, you are trying to select the iframe containing the media files, but for the functionality of Inline Attachments, I had to change the ID of it, so my iframe has the ID »inline_attachments_iframe«. I also can't change it back to TB_iframeContent, because than it would interfere with the thickbox iframe. Can you think of another way of selecting the iframe or also just also check for "inline_attachments_iframe"?

That would be great!

Hi!

I need to add attachments to posts and would like to contribute this feature here.

A very strange issue; by activating the Events + plugin I no longer get back all the content when editing an entry created by Developers Custom Fields!

http://premium.wpmudev.org/project/events-plus/

To recreate:

• have Events + deactivated
• create a simple Custom Fields content type
• add a post with above type with some content
• activate Events +
• edit the above post
• about 50% of the content doesn't come back, random items each time

Hello-

I have a couple of text-type custom fields added to image attachments, and it seems that once they're filled, I can't remove the contents - if I delete them and save the changes, the text just re-appears.

It'll let me save a change to the contents, but it won't let me remove the text altogether.

As a suggestion, compatibility with WordPress's mu-plugin feature would be great. mu-plugins are "must use" plugins that are always activated and can't be deactivated unless they are removed form the mu-plugins folder by FTP. Since Developer's Custom Fields is used for development and functionality on live sites, the ability to be used as a mu-plugin would be an added feature to ensure the plugin is not deactivated by an end user. See http://codex.wordpress.org/Must_Use_Plugins

Exists here ability for loading a metaboxes with hidden style? If yes, how can I do it, please?

The field descriptions need to be located between $before_input and $after_input when the field is a user field, as these are the opening and closing td tags.

There's a conflict with DCF when a plugin adds custom image upload fields to a taxonomy. I encountered this twice in the past week, once with WooCommerce (product category images) and once with the Taxonomy Meta plugin. When you use a custom upload field on a taxonomy, it allows you to upload the image like normal, but the blue "Use image" button is disabled and so the image can't be selected.

This is caused by a JavaScript error:

ReferenceError: slt_fs_new_upload_button is not defined

By deactivating the DCF plugin, this message goes away and the upload works like normal.

The quickest and simplest way to reproduce it is to install the Taxonomy Meta plugin (http://wordpress.org/plugins/taxonomy-meta/) and add the following code to your functions.php:

function jb_register_taxonomy_meta_boxes() {
    if (!class_exists('RW_Taxonomy_Meta' )) return;

    $meta_sections[] = array(
        'title'      => 'Image',
        'taxonomies' => array('category'),
        'id'         => 'cat_img',
        'fields' => array(
            array(
                'name' => 'Category Image',
                'id'   => 'image',
                'type' => 'image'
            )
        ),
    );

    foreach ($meta_sections as $meta_section) {
        new RW_Taxonomy_Meta($meta_section);
    }
}
add_action('admin_init', 'jb_register_taxonomy_meta_boxes');

Then try uploading an image to a standard category. Note that with WooCommerce, sometimes it worked and sometimes it didn't. With Taxonomy Meta, I got the JavaScript error every time - though I didn't spend as much time with it so maybe it would have worked on occasion.

The query on this function isn't working correctly and is unreliable at the least (didn't work at all on my wordpress 3.5.1 site, causing the admin meta boxes to display saved fields on the second query only)

The problem is the LIMIT statement without a preceding ORDER BY statement.

I fixed the error with this:
st-cf-lib.php @ 168

$field = $wpdb->get_results("
SELECT meta_value
FROM $table
WHERE meta_key = '$key'
  AND $id_field = $id
ORDER BY $id_field
  LIMIT 1");

A couple of things related to color preview functionality:

1. If an invalid color is entered, the JavaScript will set the background-color property to "none". This should instead be "transparent", as "none" isn't a valid value and is discarded by the browser. Right now, if you set a valid hex color and trigger the preview, and then go back and set an invalid hex color, the question mark will overlay on top of the previous color rather than removing the color.
2. I would also suggest adding a semicolon after the "&nbsp" in the other condition, a couple of lines up from there. I think most browsers would interpret it correctly as an HTML entity, but just for the sake of posterity!
3. The color preview will set a "?" character if the chosen value is invalid. This is just an opinion based on my own use cases, but I feel like it'd be better to not display anything at all and just leave the box blank if the color is invalid. There are a lot of situations where it's not necessarily an error if a valid color is not selected or entered. For instance, right now I'm working on a feature where the user can choose from five available brand colors via a select list, or a sixth option called "Custom". If they choose "Custom", the next field allows them to put in any hex code they want. But with the current behavior, one of these fields will always display a question mark, whether they use a preset color (and leave the Custom Color field blank) or if they select Custom from the select list (which is an invalid hex value) and then enter a valid hex value.
4. Just a cosmetic thing, but: I make heavy use of $label_layout = 'inline' to keep the fields looking nice. The color preview renders as an inline-block, but it comes after the description which is block-level. If I leave off the description, the preview displays in-line with the field and looks great. But if I do need to use a description then the color preview shows up on its own line after the description and it looks kind of clunky. Would it be possible to render the color preview element before the description if the $label_layout is 'inline', but render it after the description (current behavior) if $label_layout is 'block'?

Need to facilitate localization for the jQuery datepicker. http://docs.jquery.com/UI/Datepicker/Localization

When listing users ( 'options_type' => 'users' ), it would be useful to specify the format in which these are listed on the backend. At the moment it shows usernames, which are often somewhat cryptic. Less technically-inclined administrators would no doubt prefer full names (e.g. user_nicename).

When a WYSIWYG field set up by the plugin is put into fullscreen mode, there are no Media Upload controls. Also, when you revert to normal, any images inserted into the WYSIWYG vanish (they are still there, and reappear if you save the post).

After the upcoming update that allows multiple markers on a map, add the ability to restrict the number of markers to a maximum value.

http://wordpress.org/support/topic/woocommerce-admin-widgets-freeze-the-admin-dashboard

Also noted happening with plugins other than DCF. However, even if WooCommerce fix things, it's probably a good idea to target the DCF JS so the scripts aren't on pages where they're not needed.

There seems to be an issue here - perhaps to do with the way WP handles usermeta field names. Need to confirm and pin down, but for now it seems best to avoid dashes in field names for users.

I'm having a hard time loving the new color picker. It's nothing related to your implementation - I checked the plugin's demo site (http://www.eyecon.ro/colorpicker/) to verify that my gripes are all happening there as well. (Tested in Chrome and Firefox so I don't think it's a browser thing.)

My gripes: It seems weird that you have to actually drag in order to select a color rather than just clicking. It's also weird that you have to click the tiny little button in the bottom-right in order to confirm the selection of the color. I feel like it should update the field as soon as I choose a color, or click out of it, or that it should at least have a much bigger or more obvious button to click to set it. And just cosmetically, the dark UI clashes a lot with WP's admin and looks really dated.

It looks like it hasn't been updated since 2009, so I wonder if maybe it used to work better than it does? It just seems like it has some glaring usability issues, and for such an otherwise-complex jQuery plugin, it seems to miss the mark on a couple of really easy things.

I'm wondering if Spectrum (http://bgrins.github.io/spectrum/) would be a better choice for the color picker? It can be used on its own or as a polyfill for the HTML5 "color" input type. So in DCF, you could either go native HTML5 with a fallback to Spectrum, or just use Spectrum straight up without bothering with HTML5 just yet. It's got some pretty good traction, being used in the dev tools for Chrome, Safari and Firefox. It looks nice, is user-friendly and has plenty of customization options.

Anyway, more of a suggestion than a bug - give us an inch and we'll take a mile, right? :)

I've not noticed this before, but on a clean install of 3.4.1, the zoom level doesn't seem to be being saved when I update a post with a map field. This is with the latest 0.7.3 plugin.

This function is certainly broken, returning the query object instead of just the posts.

It may even be fundamentally broken - the usort() seems to just override the sorting by custom field.

Not sure whether to fix it or remove it?

The field that helps auto-find addresses uses the jQuery UI autocomplete method. This was dropped from WP core in 3.0 in favour of suggest.

Until we can convert the code to use suggest, the best workaround is the one that meant the issue never arose during initial development. We were always on WP 3+, but we were also always using the Use Google Libraries plugin - the Google version of jQuery UI includes autocomplete.

Currently this doesn't work - no easy way to hook some JS to run after the image is uploaded by Flash, to insert the controls.

For now, if SLT_CF_USE_FILE_SELECT is set to true, the Flash uploader will be disabled.

This functionality will be re-assessed in light of WordPress 3.3's new media uploader.

I've not tested this yet, just noting Andrew Nacin's comment (http://wpdevel.wordpress.com/2011/12/07/whats-new-javascript-in-3-3/):

Of note, there’s one pretty big gotcha: If you use wp_editor() to render the visual editor in a meta box, you risk problems. TinyMCE does not support being detached/moved in the DOM, which would occur when a meta box is dragged. (I’d look into the edit_form_advanced hook to render additional editors.)

In 0.9+, when you use the Select File button, the search box in the media overlay is hidden by the list of files to be selected.

Also, if you manage to search, the results list has no "Select" buttons.

It looks like this might be time to overhaul the file select functionality, since the current modal overlay for selecting media is very different.

Is there a way to not strip any tags? I am putting javascript in a textarea field and it's stripping <!-- and <![CDATA[ content