Loading Profile...
Here's the situation.
* I have a entries tag with a reverse related entries in it grabbing playa data from another weblog.
* The correct relationships are showing up, but its also showing entries that previously had been related but since have been removed.
* If I add a new relationship, it appears (but the other old relationships are still there too).
* If I remove that relationship I just added, it doesn't get removed from the output.
I cleared all cache and don't have 'Cache Dynamic Channel Queries' on or anything.
I peeked at my database: It seems the data in exp_weblog_data for the playa field is getting updated and is showing the correct relationships. So it seems it grabbing the extra info from the revererse_rel_data in the exp_relationships table, but I don't know why.
I also have the following parameters on the entries tag:
weblog="times"
disable="categories|category_fields|member_data|pagination|trackbacks"
dynamic="off"
show_future_entries="yes"
orderby="date"
sort="asc"
year="{embed:year}"
month="{embed:month}"
day="{embed:day}"
I thought the show_future_entries was screwing it up, but I tried it without and got the same result with past entries.
I feel like I've had this issue with Playa before, and always just solved it by deleting the entry and making a new one, but it seems to be sticking everywhere on this one.
Any ideas?
Help get this topic noticed by sharing it on
Twitter,
Facebook, or email.
Twitter,
Facebook, or email.
Reverse related entries + Playa displaying wrong data
-
I'm pretty sure {reverse_related_entries} just uses the exp_relationships table. Can you check to make sure the appropriate row is getting deleted from that?Comment
-
-
It would appear thats what's happening. It doesn't look like anything is getting deleted from exp_relationships. Every time i publish a new row get put into the table for each playa relationship. But if I remove all relationships, nothing gets deleted from the table. And what I'm seeing displayed is whats in that table.
-
-
Bummer...I did some more testing on this.
Totally vanilla 1.6.7 build 20090320 install, no extensions but Playa 1.3.6 installed and got the same results.
Adding new relationships will add those new entires to the reverse_related loop, but removing the playa relationship does not remove the entry from the tag output. Nor does clearing the relationship cache.
I can't believe I haven't run into this before. I use Playa with reverse_rel all the time! Can anyone else confirm my results? -
-
I also tested the exact same setup with a standard EE relationship field, and it worked as expected.
-
-
Hi Tim, I remember having a similar problem, where the wrong relationship information was being displayed. From what I remember, I disabled Playa, removed all relationship references in the DB and reinstalled the latest version - that seemed to sort it out.
Not sure if that's any help given you've tried a fresh install. I'll try to reproduce the error - and confirm if get the same results.-
Forgot to mention that the problem seemed to to be caused either by relationships created in an earlier version of playa, or native ee relationships that were still in the relationships table...
-
-
-
-
-
Thanks Brent, I'm going to try that out right now. I'll let you know what I find.
-
-
2Ah HA! It would seem that 1.3.6 is the culprit!
To make sure I wasn't going crazy, I made a totally fresh EE install with nothing but playa installed. I grabbed 1.3.3 from brandon-kelly.com. Worked as I always thought it did.
Then I installed 1.3.6 from GitHub. My problem returned! -
-
Good to know. I'll try to see what's changed that might cause that.
-
-
-
I have noticed the same issue with version 1.3.6. Removing relationships does not delete the records from the exp_relationship table, and I discovered that each time the record is saved, those relationships are added again to the exp_relationship table.
We did not notice the issue until we attempted to use the reverse related entries which displayed additional items that we thought were deleted. The duplicates are not displayed when using the related entries tags.
I managed to isolate where I believe the issue occurs. Here is the code block:
// Get existing rel_id's
$existing_cell_data = $DB->query("SELECT {$field_id} field_data FROM exp_weblog_data WHERE entry_id = {$entry_id} AND {$field_id} != '' LIMIT 1");
For example, we have a playa field with an id of 18. If I run the above query manually :
SELECT field_id_18 field_data FROM g1dev.exp_weblog_data WHERE entry_id = 113 AND field_id_18 != '' LIMIT 1;
the result in field_data is : [335] Crime in Focus [336] TerrorRisk WP.
However, when I display the data captured within the Playa process update_relations() for the same entry (113) with field_id_18, the data shows as: 97,111. The data being captured is actually the rel_child_id's which are 97 and 111 in this example. I checked other related entries to verify that the rel_child_id's are what is being returned.
As a result the it does not find the rel_id's needed for the process that would update or remove the entries from exp_relationships.
We are running on version 1.6.7 for expression engine, PHP 5.2, and MySQL 5.0.
Any ideas? -
-
I'm having this exact issue on devot:ee.
ExpressionEngine 1.6.7, Build 20090122
Playa 2.0.4
Many entries are affected, but here's an example: Checkboxes (http://devot-ee.com/add-ons/extension...) is a Mark Huot add-on. It was previously incorrectly assigned to Solspace. Although the Playa field has been changed and only shows Mark Huot as the dev, if I go to Solspace's developer page, the reverse_related_entries loop is still showing Checkboxes as one of their add-ons.
Clearing relationship caches doesn't fix anything. I looked in the DB (exp_relationships table) and there are still 2 relationships there for the Checkboxes add-on, where there should only be one. I don't think the relationships table is being updated correctly when saving. -
-
Hey Ryan,
I'm unable to reproduce this. When I delete an entry, each of its rows in exp_relationships is getting deleted successfully. Moreover, the task of deleting rows from exp_relationships is performed by EE, not Playa.
If you can provide me access to a non-production machine that this is happening on, I can look into this further. -
-
I'm going to update to 1.6.8 and see if I still experience this problem. I will post back here if I'm still seeing it. -
-
I’m
concerned.
Hi, I'm having the same issues as above. I'm running 1.6.8. The rows appear to be deleted from the ffmatrix/playa fields, but in reverse_related_entries, the wrong information is showing up.
Clearing the cache doesn't help. Any ideas? -
-
Similar issue for me too on 1.6.8 , using Drop Pane with Playa 2.13 and then 2.14 (both with FieldFrame 1.4 and running a bunch of add-ons). Currently have about 300 entries available via Drop Pane, all from one child weblog (FYI: the parent weblog is unusually complex; it has more than 60 custom fields, including several playa fields and a number of FF matrix ones.)
Client said that occasionally the Drop Pane in 2.13 acted strangely. They put a few entries in the right pane, saved, and upon returning noticed many more entries in the right pane. After moving all entries from right pane back to left pane and saving again, templates using playa tags continue to work just fine... BUT templates using standard EE reverse entries still display the prior related entries. Those relationships still remain in exp_relationships.
I just tried adding a single entry via the Drop Pane and then removing it. It seems to have been removed from exp_relationships as expected. But it's very late at night right now and I will need double check that result tomorrow, as well as set up a simpler test case, hopefully tomorrow too. -
-
Confirmed: if I drag a single entry to the right Drop Pane, save, and then later drag the entry back to the left pane and save again... reverse-relationships act normally and exp_relationships db table has the expected records.
My client was using Firefox and Playa 2.13 so *hopefully* this is/was related to the "freeze while dragging" bug addressed in 2.14...
Meanwhile, I'm going to ponder the best way to find the hundreds of rows which need to be directly deleted from a exp_relationships table containing thousands of rows. Maybe by clearing the cache, optimizing the table (otherwise it's > 80 mb in size), sorting on the rel_parent_id with a mysql gui client, and looking for unusually long runs of the same rel_parent_id... If anyone has better ideas, please share. -
-
Sam was onto something: If you create a relationship within FF Matrix, and then delete its row without deleting those relationships first (and re-saving the entry), the relationship won’t get removed from exp_relationships, and {reverse_related_entries} will still pick it up.
I’ll look into a fix for the next release, due any day now. -
-
In my case the field type is just plain Playa and the UI Mode is "Drop panes with filters". The Playa field is *not* within a FF Matrix.
-
-
We had this similar issue with the playa extension - version 1.3.6 (pre Field Frame). To clean up the orphaned records issue in the exp_relationships table, I wrote a script to find the orphaned records and allow me to delete those items.
For our purposes, I setup a section in EE and created a template with the php code. Using a template permitted other users (as well as myself) to run the process directly from within the site.
Because we are running a multi-site installation of EE, I provided a form to allow for site selection. I utilized jquery to perform the necessary ajax calls.
If you are interested, I can post the code that I created for the template. -
-
Angie, I would be interested in your code to find orphaned relationship entries. I'm pretty certain I still have orphaned entries left over from an earlier version of Playa.
-
-
I’m
thankful
I'd be interested as well... thanks for offering! -
-
-
-
-
-
-
-
Thank you Ryan for letting me know about pastie.org
Here is the correct link to the code: http://pastie.org/pastes/908211.
The uploaded image shows how the information was displayed on the page after a site was selected.
For the Field Frame playa fields, the field_type in the query will need to be fType_id_#. For example, if the field frame fieldtype_id is 8 in the exp_ff_fieldtypes table, change the query to:
"SELECT Concat('field_id_',w.field_id) As field_id, w.field_name
FROM exp_weblog_fields w WHERE w.site_id = $site_id AND
w.field_type = 'ftype_id_8' ORDER BY w.field_id"
I hope this information will help you.
Removing the orphaned records helped to resolve some of our performance issues. By the time we discovered the problem, we had 2500+ orphaned records. -
-
Angie, thanks so much for sharing your code with the community. If my problem reoccurs, I'll be sure to try it out. I'm sure it's way better than manually deleting the orphans, which, although pretty fast in my case, would get tiresome fast.
-
-
I’m
frustrated
Hi - Sorry to re-awaken this thread but I'm having the same problem with:
Playa 3.0.8
EE v2.1.0 Build 20100810
To confirm the problem - when using reverse-related-entries on Playa fields I am getting results for relationships that have been deleted.
I am going through my DB manually at the moment and deleting the relationship rows that should not be there, but this is a patch rather than a fix - I need to make sure that changes to relationships made with Playa in the future will show up correctly.
Is there a known fix/workaround for this issue now? I have a site-deadline looming and these erroneous reverse-relationships are starting to worry me.
Also - I don't suppose anyone has had to update Angie's orphan script for EE 2 yet? (If not, and I find I have to do so, I will post the updated version on here.)
Charlie -
-
I'm with Charlie... I'm having this issue w/ same EE/Playa combo. I'm not sure what I'm looking at in the relationships table. -
-
I’m
anxious
I posted on a a thread in the EE formum and a moderator said to come over here as they cannot replicate w/ a standard relationship field - http://expressionengine.com/forums/vi...
I posted more specific information on my issue there but can repost here if that's easier.
At this point reverse related entries is unusable and no clue how I'm going to change a section of my site to compensate - nothing I try works.
any help greatly appreciated... -
-
I’m
unsure
bump... anyone have any ideas? -
-
Sorry, I’m aware of the issue, and we’ve been working on a fix for the next major release.
-
-
thanks Brandon. any idea of timeframe for the fix?
just wondering if i should just make due until then or if we'll need to rethink the structure. -
-
Probably late next month. We're pretty much redoing the way Playa relationships work.
-
-
-
-
For what it's worth, I seem to have ran into a similar issue. Created a field used for reversed related entries, then deleted it when specs changed, now I can't get rid of the relationships in the DB... reverse_rel_data keeps on being repopulated when an entry that had that custom field is re-saved.
A fix would be most appreciated!
Thanks. -
-
I’m
anxious
I have this problem too. Is there a fix yet?
-
Earlier this month I said "late next month". That hasn't changed.
-
-
-
-
-
I’m
sad
Brandon,
Is there anything we can do in the interim, before your next release, to resolve this manually on the database? Our client's site is showing inaccurate reverse entries and I'm not completely certain what needs to be edited/deleted in the database tables. If there's any guidance that could be provided, it would be greatly appreciated. -
-
You can prune out old relationships by finding and deleting them in your exp_relationships table.
-
-
I’m
unsure
Is how that's done documented anywhere? i have looked in the DB and get a bit confused as to what's being used and what's not.
i just have been crossing my finger that this is resolved before my site goes live. -
-
If you see a reverse relationships on your site that shouldn't be there, find the child and parent entries' IDs ("parent" being the one showing up in your {reverse_related_entries} tag). Then find and delete the appropriate row in exp_relationships, where rel_parent_id is the parent entry's ID, and rel_child_id is the child entry's ID.
-
-
As I mentioned in my previous comment though, when you delete the entries in the database, they come right back up like magic when you re-save the entry... Where else could it be coming from? I to really need to get rid of this a way or another... "manually" is fine... Just can't figure out how... Thanks!
-
I think your issue is slightly different than what this thread is about. Can you try posting a new thread, with a detailed description of what you're seeing?
-
-
-
-
-
Any update? My site is about to go live and it would be pratically impossible for me to manually delete these mostly because we will have hundreds of members editing a playa field in multiple channels.
thanks! -
-
It's turning out to be a bigger deal than I originally hoped. I'm shoulders-deep in working on big updates to both Playa and Matrix which will fix this once and for all, but they won't be ready until early next year. (Let's go ahead and say Feb 1, 2011.)
-
-
I sure hope this problem goes away soon, because although I'm totally unsubscribed from following this accursed thread, I still get an email every single time someone posts here. That's as "ghost in the machine" as these mysterious REL entries.
-
-
I'm having the same problem. I know it's being worked on and know the workaround, I'm just commenting so I'm informed when it's fixed.
-
-
While Playa 4 is going to fix this issue once and for all, I'm putting the finishing touches on Matrix 2.1 and Playa 3.1, which will fix a big part of this issue – that relationships aren't deleted when a Matrix row is removed.
Do any of you have time to beta test these updates in the next week? (Keep in mind we've got Thanksgiving on Thursday ;)
If so, email your Playa and Matrix license keys to support@pixelandtonic.com. -
EMPLOYEE
