Please see:

http://codex.simple-press.com/codex/plugins/our-plugins/available-plugins/plugin-add-identities/

Thanks, but the codex instructions seem incomplete. Adding this:

function sp_PostIndexIdentityDisplay($args=”, $toolTip=”, $identity);

Results in this error:

Parse error: syntax error, unexpected ';', expecting '{' in ********wp-contentsp-resourcesforum-themesiamitemplatesspTopicView.php on line 120

Ideas..?

Thanks!

Yes a placeholder as details in work since it’s a brand new plugin.

The current details assume small amount of php knowledge. Obviously will expand when we can to not need that.

What you see if the function prototype. You want to call that function with your arguments. So:

IPostIndexIdentityDisplay($args, $tip, $identity);

And replace $args with any special args you want. Try ”

Replace $tip with the tooltip you want to see on hover over the icon. It’s a string so ‘my identity’) for example.

Replace $identity with the name of the identity you created. It’s a String, so for example’ my identity’

What

Mr. Papa, I think your reply got cut off or is missing some formatting… 

I tried sussing through it, though — changed the code to this:

function sp_PostIndexIdentityDisplay($args=”, $toolTip='Amazon Author Page', $identity='Amazon Author Page');

Still getting an error:

Parse error: syntax error, unexpected T_STRING, expecting '{' in ....wp-contentsp-resourcesforum-themesiamitemplatesspTopicView.php on line 121

Any additional guidance you can provide (or anyone else!) will be appreciated. Thanks!

Matt,

Use something like this:

sp_PostIndexIdentityDisplay('','Amazon Author Page','Amazon Author Page');

Make sure “Amazon Author Page” is exactly what you have for the identity name setup on the admin page.

You got it, Brandon! That worked on spTopicView.php — thanks!  It’s probably enough to expose the feature to public beta-testers.

I’d still like to see the Identities plugin integrate with Simple:Press in all the other places one would expect. I guess I’m a little baffled that the plugin was released into the wild (seemingly) half-done.

I’m committed to using Simple:Press (just paid for a year of support) over bbPress or BuddyPress, but I confess I’m a little disappointed that plugins don’t work “out of the box” without code-level manipulation.

Looks like I’ll be getting money’s work out of this support forum..!

Thanks again!

Matthew Selznick said
You got it, Brandon! That worked on spTopicView.php — thanks!  It’s probably enough to expose the feature to public beta-testers.

Good deal. Sorry there wasn’t all the information in the codex you needed but now that I looked at it I will go ahead and complete the information. After that you will see it can be added just about anywhere in the forum pages and with some fancy CSS or wording can do a lot of different things.

I’d still like to see the Identities plugin integrate with Simple:Press in all the other places one would expect. I guess I’m a little baffled that the plugin was released into the wild (seemingly) half-done.

I wouldn’t consider the plugin half done. Just the documentation.

I’m committed to using Simple:Press (just paid for a year of support) over bbPress or BuddyPress, but I confess I’m a little disappointed that plugins don’t work “out of the box” without code-level manipulation.

Thanks again!

Several of these special type plugins do require you add something into your theme to display the information.  Not really that unusual in the WP world. IE, add a plugin, setup the features and then add something widget wise or in a page/post to display.

This makes it so that you can put them just about anywhere and you are not stuck with some kind of default icon or description. Which is what the request for this plugin was kinda in the first place. People wanted a identity plugin they could call anything they like, with a description, icon and layout of their choosing.

Replying via email as on road…

Remove the word function…

Remove stuff left of =3D sign including =3D… Only pass the strings…

Half done??? No clue what you mean…

If you mean the docs, fair enough, but the plugin is complete and offers most flexibility. We tend to err on the side of getting functionality into users hands rather than waiting for chance to get docs done.

You may want the display in one place but fixing the display to only that spot would be very limiting. Offering template tags to display in any conceivable location is power, not half done….. On Oct 2, 2012 5:07 PM, “Simple:Press Support” wrote:

> > >

No offence intended, Mr. Papa. I come at it from the basic user’s perspective — if a tool adds functionality that can’t be utilized fully without relying on time-shifted support, that’s an incomplete tool.

Functionality is awesome, and I appreciate the inherent flexibility of Simple:Press and its add-ons. (Or I wouldn’t have paid for it!) But functionality without instruction is like a knowing there’s a banquet behind that locked door, but there’s no key.  🙂

Brandon C’s added documentation is a huge help. I look forward to it (and other aspects of the codex) being fully fleshed out.

Many thanks!

Matthew Selznick said 
I’d still like to see the Identities plugin integrate with Simple:Press in all the other places one would expect. I guess I’m a little baffled that the plugin was released into the wild (seemingly) half-done.

I’m committed to using Simple:Press (just paid for a year of support) over bbPress or BuddyPress, but I confess I’m a little disappointed that plugins don’t work “out of the box” without code-level manipulation.

Yes, this. A plug-in should be plug-and-play, not plug-and-learn-php. I’m frustrated.

The identities plugin is one that does require you add something to your theme to display it. There is just no way to create it so that it’s plug(in) and play. It is designed on purpose to allow you to create any identity and put it anywhere in your forum. If it was plug and play you would be stuck with wherever someone else thought it should go and what it should say.

The codex info on how to use it explains how to use it but there could be more info in the forum > Plugin page that explains where to get the info and why. I’ll bring that up in the ticketing system for review.

I really dont understand what plug in play means here… where do you want your custom identity to show up? I can assume you mean with the other type identities, but do you want it first in the list?  last in the list? somewhere in the middle? or on a new line above the current ones?  or perhaps below?  each user has their own unique requirements of where they want to locate something…

Where possible, we will always go for power and flexibility for the users – not rigidness and limits…  I would much, much rather spend time in the support forum helping folks to use a template tag and get it exactly the way they want than tell them they cannot do something because we didnt make the system flexible enough…

if you look at an sp theme, or wp theme for that matter, you will see they are typically just a series of template tags with some php for control… seems to me like a natural progression than any new display elements would also be displayed with a template tag like the current template tags…  allows maximum flexibility and customization for users…

I think the frustration might stem from the way (most) plugins work in the rest of the WordPress world: they add functionality that is accessed via a widget in an aside / sidebar, via a shortcode, or, if the user chooses, via a template tag directly in the theme.

Since the UI of SP lives entirely in a single WP “page,” plugins mostly can’t be exploited in widgets, because widgets live in sidebars and you just can’t have a sidebar in a page in WP. Similarly, you can’t use shortcode because shortcodes live in the content of a page, and SP creates all of its content dynamically within the page.

SP is inherently flexible, and that’s a very good thing. Unfortunately, it’s not practical for most end-users to take advantage of that flexibility unless they also have experience as WP theme developers. To be most successful, I’m guessing SP wants to be attractive to the average end-user while still having great bells and whistles for the theme developer.

Mr Papa mentioned that he’d rather spend time in the support forum helping folks than build a less flexible SP. That’s commendable, but here’s a suggestion that would be more efficient for all involved:

Complete the SP documentation, and make sure it’s presented in a linear way and written to be as understandable as possible for the average end user (not the average WP theme developer.)  Also, don’t release a plugin until its documentation is complete and written to the same standard as the SP core docs.

Since access to support is a big part of the SP business model, put all the documentation (except for installation and upgrade) behind the paywall.

The advantage to users is obvious. The advantage to the SP staff is considerable, too: complete, clear documentation means staff spends less time answering questions in the forums — time that can be spent working on the product itself, which I’m sure is a big priority.