Playa

As I’ve mentioned, that’s definitely soething I want to look into when I have the time. In the meantime, you can use the Publish Page Improvements extension to remove the Quick Save button.

I don’t think the Quick Save problem is solvable on this one - seems that Mark Huot was looking into this and where the hook for that lies. Info for that can probably be found in his older Multiple Relationship thread.

And yes…if I’m ever using one of these multiple-relationship extensions, I always make sure to hide that Quick Save button!

I really wish this type of field was built-in. But thanks for your work making it happen now.

Just thought of a very simple solution to this problem: As soon as you’ve modified a Playa field, the Quick Save button becomes disabled. That way, you can still keep it around for all edits that don’t involve a Playa field.

Playa has been updated to v. 1.0.9

Playa has been updated to v. 1.0.9

And the updates this time are ? 😉 😊 😉

Best wishes,

Mark

Well, fuhgetabout the simple core file hack I’ll have to do for this thing…I have to use it on this build. And the idea that the QS button can be disabled - clever solution! I’ll ping this thread if anything doesn’t work out. Thanks, Brandon.

Is anybody else having trouble when using Playa with Textile Editor Helper (the textile WYSIWYG toolbar)? It looks like when TEH is enabled, the Playa javascript file doesn’t load for me.

Brandon, am I correct that the Playa extension was developed for Navigant Consulting’s website in order to link professional biographies to practice areas, and also to publications authored by a certain professional? This solves that problem very neatly.

Brandon, am I correct that the Playa extension was developed for Navigant Consulting’s website in order to link professional biographies to practice areas, and also to publications authored by a certain professional? This solves that problem very neatly.

In the Professionals section, it’s used to link them with their Industry Expertise and Industry Specializations, but nothing related to publications.

The challenge was that Navigant wanted to be able to select an unlimited number of Expertise/Specializations per professional (for search purposes), but they only wanted four of their choice to show up on the bio. Their previous system did this in two steps: 1. Check each Expertise/Specialization that should be searchable; and 2. Select the four that will show up on the page using separate drop-down menus.

I hated that solution (I only wanted one list), so I created Playa. It allows an unlimited number of selections, and they can drag the four selections they want to be visible up to the top.

Is anybody else having trouble when using Playa with Textile Editor Helper (the textile WYSIWYG toolbar)? It looks like when TEH is enabled, the Playa javascript file doesn’t load for me.

If playa.css and playa.js aren’t getting loaded, TEH is probably not checking for other extensions using publish_form_headers hook. You could try disabling and re-enabling Playa, to give Playa a lower priority than TEH.

.You could try disabling and re-enabling Playa, to give Playa a lower priority than TEH.

Thanks! Disabling and Reenabling didn’t fix it, but I went into the exp_extensions table and changed the priority for the Playa publish_form_headers hook row to 11, instead of 10. TEH’s priority is 10. Now it works perfectly.

Is it OK that most of the Playa records/hooks are priority 10 (except for weblog_entries_tagdata, which defaulted to 9) and that single one is 11?

Thanks again Brandon!

Is it OK that most of the Playa records/hooks are priority 10 (except for weblog_entries_tagdata, which defaulted to 9) and that single one is 11?

That’s fine. You might want to send a note to the developer of TEH and have him/her add the following code to the beginning of each of their hook functions that return data to the system, so it doesn’t overwrite the return data of other extensions using the same hooks:

$r = ($EXT->last_call !== FALSE) ? $EXT->last_call : '';

Got it– will let them know!

Looks like there’s still one issue with TEH enabled, though, even when priorities are set lower. Adding items to the selected list doesn’t update the “x of x allowed open items selected” counter, and any over the allowed items aren’t marked as disabled unless I move them around.

Edit: I don’t want to sound like a complainer, because I love this extension! But I do want to report one more issue: it looks like entries with status anything that’s not open are marked red and disabled. Should it just be entries marked closed that are marked red, or is that behavior intentional?

Again, thanks so much for the work on this Brandon.

But I do want to report one more issue: it looks like entries with status *anything that’s not open* are marked red and disabled. Should it just be entries marked closed that are marked red, or is that behavior intentional?

Right now it only displays entries marked as “Open”, since (so far as I’ve seen) other statuses are generally used for pre-published content.

I’m thinking about adding a setting for this, though, which would let you select which statuses should be considered published.

Looks like there’s still one issue with TEH enabled, though, even when priorities are set lower. Adding items to the selected list doesn’t update the “x of x allowed open items selected” counter, and any over the allowed items aren’t marked as disabled unless I move them around.

Does this still occur when you disable TEH? If so, try disabling your other extensions one-by-one to see if you can find which one is conflicting. If you still have no luck, PM me your browser/OS versions and I’ll see if I can’t try to repro it.

I have a few fixes for this extension.

1) Fix to work with a Masked Control Panel For the record, the way the paths are written to the CSS and JS doesn’t work with masked Control Panels. I went over this with Mark Huot on one of his extensions before (seems I’m about the only person who actually Masks the Control Panel…)

Anyway, altering the following change will allow it to be a little more flexible.

In ext.playa.php change:

function add_header_includes()
  {
    global $EXT, $DB;

    // -- Check if we're not the only one using this hook
    $r = ($EXT->last_call !== FALSE) ? $EXT->last_call : '';

    $r .= '<link rel="stylesheet" type="text/css" 
    href="extensions/playa/playa.css?v='.$this->version.'" >
    version.'">
    <!--[if IE]>playa_ie=7<![endif]-->
    <!--[if lte IE 6]>playa_ie=6<![endif]-->';

To:

function add_header_includes()
  {
    global $EXT, $DB, $PREFS;

    // -- Check if we're not the only one using this hook
    $r = ($EXT->last_call !== FALSE) ? $EXT->last_call : '';
    $sysfolder = $PREFS->ini('system_folder');

    $r .= '<link rel="stylesheet" type="text/css"
    href="/'.$sysfolder.'/extensions/playa/playa.css?v='.$this->version.'" >
    version.'">
    <!--[if IE]>playa_ie=7<![endif]-->
    <!--[if lte IE 6]>playa_ie=6<![endif]-->';

2) Fix to work with Textile Editor Helper In the add_header() function, add this somewhere before the first ‘$js’:

$js = ($EXT->last_call !== FALSE) ? $EXT->last_call : '';

Then change that first ‘$js’ line from:

// Set up dependancies and engage    
$js =

to

// Set up dependancies and engage    
$js .=

That seemed to do the trick for me. Update: This doesn’t entirely solve the problem. You can move things to the right side, but the count doesn’t update, you can’t reorder them, and they don’t grey out. Turning off the TEH solves everything.

One other thing I noticed is that there is a reference to a navigant server in the playa.js file (referencing the collapse/expand graphics).

I still don’t think I have it working 100% - but that may be because I’m masking the control panel. I’m not able to r-order teh stuff on the right side, and the Quick Save button isn’t deactivating. I’ll try accessing the CP without masking to see if that helps - I also may have missed changing something else in my masked CP fix. Checking now…