johnywhy

hi, thx for helping a noob ??

i’m having a little trouble understanding your reply, basically it seems you’re saying the above-quoted article (written by the editor of the WordPress section on Smashing Magazine and contributor to WPMU DEV) is not correct. Are you?

isn’t an issue by itself

What do you mean “isn’t an issue”? So, get_var does not require prepare?

Is get_var vulnerable to injection attacks, even though it’s just reading the db?

escape ever other value that goes into an SQL query

What do you mean “value”? You mean every other word in the SQL statement? Or, values in a table-insertion? Or, just the keywords?

if you use the standard $wpdb functions like $wpdb->insert() or $wpdb->update() these functions do the excaping for you.

I believe i am using a standard $wpdb function. Here’s my code:

global $wpdb;
$query = “SELECT ID FROM wp_t9s5y8_bp_xprofile_groups WHERE name = ‘Apprentice'”;
$result = $wpdb->get_var($query)

+1
me too.

Un-be-liev-able. You ROCK, donmik!. Ok, now i’ll have to study this ??

Hi

i’m still learning, but i have some thoughts about the new plugin:

It seems to me that if we’re extending a class, then it’s safer to let the parent execute it’s own code, instead of copying the parent code verbatim to our own class. I believe a benefit of inheritance is that you inherit the parent’s functions, and only new code should go in the child– just as you do in the constructor.

So in the function admin_field_html, i suggest this change:

...
    // Original code of buddypress class.
    // Call the parent
    parent::admin_field_html();

    // and remove code copied from the parent

    ...

====
same thing in function edit_field_html:

...
	// Original code of buddypress class.
	// Call the parent.
    parent::edit_field_html();

    // and remove code copied from the parent
    ...

====
function admin_field_html is a bit different. here’s your current code:

...
    // The original $richtext_enabled flag.
    $richtext_enabled = bp_xprofile_is_richtext_enabled_for_field();

    // I'm looking inside the options to check if the checkbox "disabled_richtext
    // for this field is checked.
    $options = $field->get_children();
    foreach ($options as $option) {
        if ($option->name == 'disable_richtext') {
        	// Found it, so $richtext_enabled should be false
        	$richtext_enabled = false;
        	// Stop looking for it, just in case.
        	break;
        	}
    }

    // Original code of buddypress class (copied from parent class)

Like the previous function, you’re again inserting the full body of the parent fx. So again, i want to do a call to the parent fx, instead of copying the parent code into your fx.

Problem is, unlike the previous examples, we can’t just insert a call to the parent, because your code is inserted in the *middle* of the parent fx.

// First you do this line, copied from the parent:
$richtext_enabled = bp_xprofile_is_richtext_enabled_for_field();
// then your own code, to test the checkbox.
// and then you execute the rest of the parent code.

This makes me think the parent classes are not consistently-structured.

Is it necessary to do $richtext_enabled before your code? If we can put that after your code, then we can call the parent fx instead of copying it.

thx!

wow, thx donmik, for listing me as contributor in the new plugin!

absolutely, fantastic, donmik!

thx for suggesting that i make my own plugin with this, but that would not be right– you built it!

hope you include this feature in your next release!

many thx!

fantastic answer!

thx for explaining why copying datepicker didn’t work, i guess i used the wrong field as a model! i used that because i wanted the html5 textarea. Will your filter give the html5 textarea?

your solution is slightly different from this other one, which helps me learn.
https://buddypress.org/support/topic/how-to-get-plaintext-multiline-field/#post-249715

i want to create a “Rich text” checkbox into the userfield editor, so users can enable/disable in the GUI. That will require:
– code to create the option checkbox in the editor.
– code to display the textarea on the front-end.

i decided to imitate the structure of the decimal control. I searched your plugin files for ‘decimal_number_option’ (which is the ID of the decimal picker html element in the editor). But not found!

Which makes me think you’re doing some concatenation of the string ‘_option’ to ‘decimal_number’ in one of your files, to get the full ‘decimal_number_option’ string. So i checked out the birthdate php class, and sure enough found the function admin_new_field_html contains:

....
                while ( isset( $_POST[$type . '_option'][$i] ) ) {
                    $is_default_option = true;

                    $options[] = (object) array(
                        'id'                => -1,
                        'is_default_option' => $is_default_option,
                        'name'              => sanitize_text_field( stripslashes( $_POST[$type . '_option'][$i] ) ),
....

nice work, donmik! very smart code! So i’m thinking must combine this code with the filter you offered above, maybe.

I also searched files for ‘birthdate_option’ (ID of the decimal picker html element in the editor), and that one does show up in admin.js, along with some other fields, but not all fields. I guess some fields need some js handling?

I’m thinking my multi-line richtext checkbox should be defined in the buddypress plugin, not your Custom Fields plugin, because the multi-line field is part of buddypress core, not your plugin. Right?

Feel free to share some clues ??

We don’t want our members formatting their bios with bold text, big fonts, colors, etc etc. We want our CSS to control presentation.

— it’s for this reason that i suggest that <textarea> is an important omission in BP fields.

But BP IS AWESOME, AND THANK YOU to all the devs who built it.

THANK YOU to donmik for the fantastic extra fields, GREAT PLUGINS!!

hope you’ll be willing to help me solve this (i know this is not the right way to build a plugin ??

i also edited the .po file, and generated a new .mo from that.

In case anyone is wondering why we would want a plaintext field:

We don’t want our members formatting their bios with bold text, big fonts, colors, etc etc. We want our CSS to control presentation.

thx, donmik! yes, i found that one.

do you know if there’s a way to get conditionals on a whole field group? Not based on user-role, but based on user-entered value on another field. i thought i saw this someplace….

thx

thx for the detailed answer.

resolved by making a simple, one file plugin, instead of using the boilerplate generator. everything goes in that file.

instructions here:
https://www.wpcue.com/wordpress-plugin-development-beginners/

thx!

discovered it only fails if BP Groups are disabled in BP settings.

on BP 2.4.3

thx

Registered to me where?

When you say “advertise”, you mean here? Or in my source files? For security reasons?

I’m not referring to the site connected to my username here. In the site I’m referring to in this thread, mydomain/readme.html says “version 2.9.2”.

It also says “In most all cases you shouldn’t modify any of the core code”. “most all”, not “all”.

Although I probably stopped updating the site you examined for the same reason.

still using WordPress 2.3!

No, I last updated in 2009 to 2.9.2, and it broke my website. Had to go in and manually fix files.