Can’t access shortcode argument

Hey @srob41,

Try to pass only $atts in function.

function email_handler($atts, $content = null, $tag = '') 
  {
  $email_atts = shortcode_atts(array('asdf' => 'no_param'),$atts);
  $lcAdr      = $email_atts['asdf'];
  $lcOutput   = sprintf('<p>%s</p>',$lcAdr);
  return $lcOutput;
  }

add_shortcode('email','email_handler');

Like that?

function email_handler($atts) 
  {
  $email_atts = shortcode_atts(array('asdf' => 'no_param'),$atts);
  $lcAdr      = $email_atts['asdf'];
  $lcOutput   = sprintf('<p>%s</p>',$lcAdr);
  return $lcOutput;
  }

add_shortcode('email','email_handler');

Same result… output = no_param

Strange! It works for me.

Use below shortcode.

[email asdf="b1"]

Instead of

[email asdf=”b1″]

Looks like some problem with double quote.

Yes, the “curly” quotes are invalid for parameters. Even once you get the shortcode working, which is a worthwhile skill anyway, I’m not sure shortcodes alone will make you email “safe” from scrapers. Of course it depends on what you have in mind and what you consider “safe”. If your plan involves JavaScript, you are probably OK, if not, I’m skeptical.

Thank you for your responses!

The quote signs are not the source of the error. My double quotes were straight, not curly. One of my first steps to overcome the problem was using single quotes for the parameter, didn’t change anything. Though I can see curly quotes in the code block of my first post here, guess that’s a product of this forum’s editor.

This morning I found something–did print_r($atts) in my shortcodes.php to take a look inside that array. It shows:

Array
(
    [0] => 
    [1] => class="xr_tl
    [2] => xr_s11">asdf='b1'
)

That looks strange… I have set the email shortcode in the WYSIWYG editor for the webpage (sorry, I have no idea how the correct terms for the WP parts in English look like, I am working with the German localization–there it is “Visuell” in the “Seiteneditor”). When I switched over to the HTML editor for the page (“Text” in the German version), I saw this:

[email <span class="xr_tl xr_s11">asdf='b1'</span>]

Removed the span element and republished: now it works!

So, what is the problem here? Was the span element added by the WYSIWYG editor? How can I prevent it from doing so? Now, in the WYSIWIG editor, I put a newline below the problematic shortcode, and added a new shortcode. This time, the shortcode was not embellished with span quotes by the editor, it worked instantly…

Later, the owner of the website will have several authors publishing content. None of them is prone to work in the HTML editor.

—

To the “safeness” of my mail solution: my plan involves JavaScript, and the final email links will look like that:

<a href="javascript:nspmml('thps{vApumv!R!~puupunlu5kl');" class="anodec">info(<span class="spae">at</span>)[...]</a>

Of course that is not perfectly safe, but it will prevent the worst. I took this path for the mail address publishing to learn more about the WP construction, not for the mail thing alone… I am certainly learning somthing now!

Robert

Yes, the forum’s parser converts any quotes that are not designated as code into ‘curly’ quotes. It’s endlessly confusing, particularly in this sub-forum. I suspected that was the reason and not the cause, but couldn’t imagine why else attributes would not be passed. I never imagined some auto-inserted span tags would be the cause! Great sleuthing, switching to text view. (FYI, the English terms for the other tab are literal translations: “Visual” tab of the page or post editor. You could have figured it out for sure through the de_DE.po language file, but such effort is uncalled for, it’s clear what you meant)

WP does automatically do some things to post content that many find annoying, but nothing like that. I suspect your theme or a plugin is the cause. If you install and activate the health-check plugin, you can use the troubleshooting tab (get there through the dashboard menu pick) to selectively deactivate modules to help you narrow down the one responsible. You can also do so manually if you prefer.

AFAIK email scrapers do not interpret JS, so your protection scheme should be fine. Not knowing you skill level, I was afraid you were misunderstanding how shortcodes work. Fortunately my fears were unfounded. Good luck tracking down that span tag insertion source.

Thanks for the hints towards health-check and the language file!

My next obstacle to overcome will be finding out: what is the right way to put my own javascript, having the scope needed and not interfering with any internal WP and theme mechanisms? I found some construct using add_action() and wp_register_script()/wp_enqueue_script(), which looks promising.

After some days of exploring WP I see my biggest problem in an overabundance of WP web information, almost all of it directed at a target group that could be entitled “web site creator with intelligence, intellect and knowledge matching that of a railway rail”. To filter out all the “Creating a booombastic WP website for dummies” noise is really cumbersome… Especially hard is to find systematic information about WP, how the whole thing is constructed and working.

Robert

LOL! You quoted phrases are hilarious! ?? in particular:

booombastic WP website for dummies

wp_enqueue_script() is the official, WP approved way to introduce JS and related scripts. Whether you need to also register or not is a bit confusing. Registering is needed in order to refer to your enqueued script in other calls, such as wp_localize_script(), or as a dependency for other enqueued script. If you are registering only to enqueue, it’s unnecessary, but will doing so will no harm.

It’s of course most appropriate for external file references. It’s a bit overkill for quickie scripts that are generally done inline. You can simply echo out minimal scripts inside of script tags where ever it makes sense. There’s a function to add inline script related to a registered script. I don’t recall it’s name offhand, I don’t find it that useful. If you need a hook for inline output, you can use the “wp_write_scripts” action, which is what the enqueuing system uses to output external link tags. Inline scripts are not so good if the script has dependencies. Inline jQuery for example, (unless you use that function I cannot recall). You can often get away with inline jQuery if it is not too extensive and you are sure to enqueue the local “jquery”. Note that the local jQuery runs in noConflict mode, so the common $ shortcut does not work out of the box.

I think that covers the scripting essentials. I’m afraid offering a reference for “systematic information about WP, how the whole thing is constructed and working” will prove to be elusive. The information is out there, but in bits and pieces. As you’ve observed, “separating wheat from chaff” is difficult. It helps a lot if you can sight read PHP code, the source code is a great reference if you are able to make sense of it. I realize that skill is probably in that railway car somewhere.

TBH, I’m not sure how important it is to really understand the whole thing. When the need for knowledge arises related to a particular task, make a detailed study of just that aspect. Rinse and repeat. Eventually you will build a decent understanding. Helping out in these forums, doing research in order to help others is a great way to broaden your knowledge. Start by answering questions you know the answer to. Broaden out to questions you think you can answer because you have an idea where to find the answer. You will eventually accumulate knowledge that you would have never bothered to learn if you had limited yourself to your own needs. It worked for me anyway ??

Here’s some general references to get you started. It’s all too much to read, but useful references. You’ve probably found the Codex, it’s old and slated for replacement, but it’s a treasure trove of knowledge and useful code snippets. HelpHub is going to be the beginner level replacement, for now it’s very much a work in progress, only a staging version currently exists. The Developer Resources are much more fully developed.

All of that does not give you a good starting point. maybe Query Overview would be a good starting point. If you really want ALL the query deets, don’t miss the first link to a humanshell.net post. Enjoy ??

Thank you very much for such an extended reply! That will be saved for further exploit…

Some of the references you quoted are on my list already. The Query Overview looks very interesting, also the WordPress Initialization post. Going to delve into it.

I stumbled into WP, because by chance I got a web project that is supposed to be realized in WP. In the pitch I gave the impression of being cool with WP (still surprized that nobody wanted to see my WP project references). My hidden agenda was to explore WP in a live project, so I could decide if it is my future way to go for a more efficient web design process. Until now, I am doing everything handcoded in Notepad++, with my own CMS that has been growing over almost two decades.

Of course, dealing WP with my perfectionist attitude of controlling every detail is an assignement that cannot be resolved. Especially not, if you’re an engineer, web developer and graphic designer at once, and your work load is spilling over the rim. With complex systems like WP you have to give up your compulsion to control everything, and develop confidence that others have created stuff that is working. It just took me by surprise that I couldn’t easily find an answer to my first, most basic question: “What is a theme? Do I need a theme at all?” Then I was struck down by the mystery of the mail shortcode. By the way, still don’t know the answer the theme question…

So, I think the decision that I will be going the WP path has fallen already. Now I can’t help from sinking deep into the developer swamp. It will be the same procedure as always, incrementally growing with bits and pieces gathered in real life problems, like you summed it up. No systematic way into it…

Robert

Heh, I hear ya, better than you can imagine ??

IMO there is nothing more efficient than hand coding. If it’s not, it’s your own fault. It’s practically impossible for average clients to generate their own content on hand coded pages. Good for getting a continuous flow of small tasks to work on, but clients might start to feel they’re being used. Part of the appeal of WP is its elaborate backend UI that makes creating content much easier. Unfortunately, I’ve found most clients are still intimidated by even this “friendly” UI and still end up calling me for minor changes. The few brave enough to try doing it themselves often screw up something basic and end up having me clean up the mess.

The fact remains WP makes up a sizable portion of all web site’s infrastructure, so you will invariably encounter it again and again when you pick up existing sites. It’s good to at least be able to dabble with WP if you want to pick up new work. If you’re that busy without knowing WP, you can afford to turn away the work.

As it happens, WP offers so many developer hooks for customizing and extending a site that if you’re willing to make the effort, you can do pretty much anything with a WP site. Except make it efficient. You actually do have a lot of control. With the speed of servers these days, the code base inefficiency is not the bottleneck, it’s image content and external files being shoved through less than ideal HTTP connections. It’s cool and satisfying to write efficient code, but for the most part it will make little difference in the overall speed perception.

Still, I totally get why you would be reticent about WP, I don’t blame you, it’s far from ideal.

Oh, you can think of a theme as the “skin” of a site. A site has certain content stored in the DB. The theme takes that content, formats and styles it for output in a certain way. You can totally change the appearance of a site by simply changing themes. The underlying data does not change, but the site appears very different. In reality, it’s not quite that simple, but that’s the main intent of themes.