e-sushi

The “?” (question mark) you are seeing means that some file you are using along the way does not support UTF-8 correctly.

You would have to open up the plugin files and make sure they are saved UTF-8 and – if possible – without the BOM (Byte Order Mark) so PHP doesn’t get confused.

If you don’t know what I mean, contact the plugin developer directly… he should be able to “correct the issue”.

Guess that your setup sets a cookie for https, but it catches itself in a loop since that cookie won’t work for http. Why don’t you throw it all into the https ring? After all, you have SSL in place – use it by simply setting it up in the configuration. (and probalby a small 301 in the htaccess to make it seamless).

You’re in luck: I use firefox and yes, firebug is up and running… and I didn’t need that screencast either. ??

Sooo, let’s dig into it…

As for what ajax returns: something I would call “a json-ed array with empty positions”. Therefore, I guess the “undefined” is a logical return we’re seeing.

Trying to narrow it down yesterday, I detected the plugin does not have a hard time doing an “initial run” on new images (as they work), but as soon as a “rerun” occurs, even those working images render non-working, returning the same “undefined” results.

My best guess – for what it’s worth – is that the plugin fails parsing the META of the images somehow. Probable a de-json thingy, where some data get’s lost due to a parsing-problem. Why? Because in case of “undefined”, none of the “undefined” images get scaled and the meta stored back in the database kills thumbnail usage by only returning the original, full-size image later on.

Love me or hate me, but I created a fresh install on my home server… created some posts, adding post-thumbnails to it. First run: all ok… 2nd run: all “undefined”, post_thumbnails return original images, not resized ones.

Wrapping it up:

-> Create a post, add a post-thumbnail to it. Works.
-> Run the plugin. Seems to work fine…
-> Checking the post… post_thumbnail(); returns the original size image, no thumb (although the thumbnail itself exists on the server)
-> Rerun the plugin again… the “undefined” message shows up AND (as before) post_thumbnail(); returns the original size image, no thumb (although the thumbnail itself exists on the server).

I might be wrong – but as said: my best guess is that there’s something wrong while the plugin parses the post-image-meta for the first time. When the plugin writes it back to the database – the thumbnail info is allready lost, so the original, full-size image data gets stored… but nothing else. Reruns of the plugin seem to be a quite good proof of that.

What you should know: I recently (last week as far as I remember) updated the plugin and I updated wordpress to 3.0.2 two days ago.

Before that, all worked. Since I can’t find anything buggy in wordpress itself that can reproduce the error, I think the answer might be found in the difference between your previous plugin version and the current one (which allready seems to be supporting the upcoming WP 3.1). If I were in a devteam with you, I would simply ask: “what did you change”?

Wow, long message. Hope it helps you. If you need any more infos, please feel invited to contact me. I will try to do my best to provide useable feedback. (Please feel invited to drop an e-mail to “e-sushi” at “gmx.net” or simply find the rest of my contact info at e-sushi.net)

@fatfred: why not use the “new” HTML5 doctype? It’ll validate and it’s “the latest hype” if your client asks! *JustSaying* ??

So, is this resolved or what?

And… after stumbling through the docs for about 60 seconds… doing YOUR job in finding the information you need:

Check https://codex.www.ads-software.com/Function_Reference/wp_login_url and https://codex.www.ads-software.com/Function_Reference/wp_logout_url.

Futhermore, this (new in 3.0) can enhance your endeavours: https://codex.www.ads-software.com/Function_Reference/wp_login_form

Seems I just resolved your problems… what I can not do for you is to learn how it works. I know (being a PHP/MySQL pro) what magic goes on behind the screens. If you’re a willing learner and know how to “feel” the code, you will understand it too in a matter of minutes.

Glück auf! ??

First up, the use hashing adds security to the whole process. Just think what happens when some “bad guy” uses scripting to hack his way into your wordpress backend. Without the propper hashes, this will be more difficult.

Also – especially for educational purposes – it is not wise to store or even transfer unencrypted data like passwords. Even MD5 can be hacked, but it’s way more difficult for “ye average script kid”.

If you really want to look at the functionality and understand it, check the docs and then lookup the related functions in the sourcecode.

Let me do your job and dive into the docs…

@jtreminio mind sharing your knowledge?

I’ve been looking for exactly the same thing and a short hint to working code would just make my (and probable the community’s) day.

Solved that one myself.

The trick is: You have to create a copy of the original form you are using for “user submit” and the copy of that form can be setup as an “edit” form.

Not all to logic, but at least it works. ??

Two sollutions:

1) The hard way…

Lookup your database using phpmyadmin or something like that… TDO Mini Forms stores the “absolute paths” when the plugin stores “file upload widgets” in a form. In the table called “wp_tdomf_table_widgets” (depending on your wordpress setup, with another prefix, so: “???tdomf_table_widgets”) you’ll find what you’re looking for… the “widget_key” column. There, every “tdomf_upload_widget?” holds the absolute path. You’ll have to change it according to your server’s path setup.

2) The easier way…

Another, shorter sollution is to open all forms you use and which contain file upload widgets. Simply do the following for each file upload widget: RemoveFileUploadWidget -> Save -> AddFileUploadWidget -> Save. Done!

That will do it. ??

@glebec: I love your sollution! Much better than those jquery “hiding” stuff. Tnx… 8]

Tip: found this info https://ottopress.com/2010/wordpress-3-0-theme-tip-the-comment-form/

Thank’s for pointing me towards new ideas! ??

@geezerd and @zatuna: what the hell are you talking about? The toppic was “how to remove” and not “how to add” profile fields.

It would’ve been cooler if you’ld contributed something that hasn’t been posted in this thread before. Simply let me point you to @ipublicis contribution. @geezerd did nothing new.

So much for my 2 cents…

The “unset” I showed you above will only work for those 3 contact methods. For the other stuff, you need other code… not nice, but that’s WordPress.

So, to dive in deeper: if you want to get rid of the “color options” at the top of the profile… simply use

add_action('admin_head', 'admin_del_color_options'));

function admin_del_options() {
   global $_wp_admin_css_colors;
   $_wp_admin_css_colors = 0;
}

This overrides the number of found color schemes to 0, preventing WordPress from rendering that “choose your color theme” thingy.

Hope you’re starting to love me? ??