Playa vs. Solspace's Related Entries

I would add a vote for this, I am developing my first EE site and would appreciate peoples thoughts. All the best

I’d love to know more about this as well. I contacted Solspace and requested any info that would help me understand the scope of the product - including a demo and example sites, but never got a response.

I also use and love interface and usability of Playa, but new version 2.03 it’s no more free product. The price is the same as the Solspace, I guess for competition fair game

Thought I’d chip in as just stumped up for Playa 2 after deliberating between the two. I’d used Playa classic previously so it had that advantage of familiarity but now with the features of filtering via weblog, author, multiple drag and drop etc… it’s got everything that the Solspace one does at least. I also wasn’t sure if the Solspace allowed more than one related entry field per entry as I need a few Playa fields for a single weblog entry.

Either way, Playa 2 is brilliant and a lifesaver and if Solspace Related Entries is even half as good it’s still worth the price tag.

I bought Playa and its great.. I don’t know much about the Solspace module, I think because they’re not so hot with the documentation / usability side of things, both in terms of their site structure and how they break down their products.

That said, I have the Solspace Tag module and it more than delivers on what I was hoping for. Overall, Brandon just makes it easier to understand his product before you purchase it.

One thing that bothers me a little bit (and I’m not db expert) is the serialised data format for Playa entries. If somebody else has a good understanding of

a) the general limitations of mysql serialised data and b) whether the Solspace module also stores serialised data in the exp_relationships table

I love to learn more about this.

The Solspace product creates and uses it’s own table in the EE database.

Playa’s approach is more inline with how EE’s relationships are stored - which allows you to use the native Reverse Related Entries tags with it.

I’ve a more in-depth comparison of the two relationship tools available via a (for purchase) Train-ee Screencast.

Cheers Michael, you made yourself 25 bucks from me for that last post. Can anyone explain how the new Erskine Labs Related Entries module fits into the picture ?

Thanks!

I’m always careful about pitching my wares here in forums…in this case though it seemed to be an exact answer to what was being asked.

I can’t recall if the Erksine tool was available when I did the screencast or if it was the version that needed a core file hack (I don’t use any 3rd party stuff that requires core file changes).

I wonder..with that one since in the end you’re within a weblog:entries loop if you could use pagination in the results. It’d be nice if they posted more about the reasons for developing/using it.

Indeed, pagination within related/reverse_related_entries would really help me a lot. At the moment I’m having to use php/mysql solutions for that.

It looks like this is indeed a feature of the Erskine module.

I have tried out the Erskine tool but can’t get it to return any entries. I thought maybe I was just doing something daft, but somebody just PM’ed me who is having the same problem.

I have tried both Playa and standard relationship fields.. It’s also not clear from the blog post whether it works with Playa or not? I’ve raised these questions on the blog post but not heard back.

Anybody managed to use this module successfully?

Hi all,

I was hoping I could help a little with describing the differences between Playa and Related Entries.

The primary differentiators are two, in our view.

First, as of Playa 2.1.0, if you need related entries functionality that can perform well under heavy site traffic load you are better off with our Related Entries module. Due to the architecture of our module and the way we query the DB to get related entries data, pages will load faster. In the case of Playa, for each relationship field you create, Playa will grab ALL of the blog entries from the DB for a given set of indicated weblogs. This is not efficient for high traffic sites or sites with high blog entry volume. We’ve crashed a few sites by using Playa. I suspect that Brandon will be adjusting for this in future versions. But we will also be improving performance obsessively for some time to come.

Second, most people, including us, agree that the Playa UI is stronger. This is the other main differentiator. In general, the UI and design work we’ve seen from Brandon is just excellent. He has a lot of depth and skill, especially in that area. This is where building add-ons for EE has suddenly gotten really fun. Now we are in a position to compete and try and be better. We’re completely revamping our Related Entries UI in an effort to offer more flexibility and a greater intuitive feel.

Luke, you also made the point that Brandon’s site and his sales pages are more approachable and easier to understand. I also agree with this. With the exception that I couldn’t figure out how to get an upgrade from 2.0.7 to 2.1.0! 😊 We are working on a Solspace.com redesign now and hope that it will address so many of the constructively critical comments we have received. We’re slow on that though. We get so distracted every time we think of another killer add-on we want to build.

At any rate, excepting the performance problems, we vouch for Playa. We use it from time to time. We adhere to the maxim of using the right tool for the job. And sometimes the ability to create a custom field that captures relationships makes a lot more sense to a client than having a separate edit page tab to handle relationships. However, sometimes the Solspace Related Entries approach makes more sense for a client. We choose the tool that will serve the client best.

For other details and more depth of comparison I would encourage all of you to visit Michael’s site: http://www.train-ee.com

mk

Thanks for the comprehensive breakdown Solspace! 😊

What you say about performance gains with your module is very interesting to me. Nearly all the sites I build require at least one weblog with 20+ fields in the publish form and several many to many relationships which I need to work reliably at scale.

I have notice issues (db timeouts, slow load times, php memory issues) with Playa on one site where the weblog structure is as described above, particularly on listing pages that produce many listing items from related entries taqs.

Upon inspection I see that Playa basically dumps the entire related entry into the exp_relationships table as serialized data. I have limited mysql knowledge but this does not seem like the best approach to me for a site with high traffic / requirements to scale gracefully. I suspect the exp_relationships table exists to cache related entries (I would be interested to know more or even be corrected on this point), but it seems to be that at scale, performance could be improved by just storing the id of the related entry and only fetching the requested fields for that entry.

Please could you tell me a little more about how your module handles the db end of things?

Thanks again for clearing this up, Luke

Luke,

Thanks for the follow-up questions.

The first thing that I want to emphasize is that Playa CURRENTLY has potential performance issues. We have crashed sites with it, but we have also quickly hacked it to fix the difficulties. These could be corrected leaving the module as a great choice for a lot of applications.

The second thing I want to say is that I am refocussing a lot of the Solspace software development efforts towards performance. Several of our add-ons can crash a site under the right conditions. We’ll be correcting those issues in the coming months. So I don’t want to point the finger at Playa without acknowledging that we have problems in our own library.

The Related Entries module has a table called exp_related_entries. It has columns for entry_id, related_entry_id and some new features we’re adding. It’s a very simple table. When you tell the module that you want to fetch related entries, it grabs the entry ids related to your blog entry from exp_related_entries. Once it has those entry ids it goes and fetches the necessary field data just like exp:weblog:entries does.

So no, we’re not using a serialized data approach. That’s a big differentiator.

mk

Excellent, thats what I wanted to know 😊

One last question - hypothetically - if I wanted to migrate a site from Playa to your module, how hard would that be? Is there some way to harvest the existing relationships before removing the Playa fields from the publish form? I know your Tag module offers something similar.