Forum Activity for @brian

updating template to jrCore_item_detail_features doesn't display prior entered tags

Using Jamroom

Yeah that's weird and doesn't look correct - open a ticket for me if you would with the site login so I can check it out.

Thanks!

Please explain new update for Profiles module

Using Jamroom

Correct.

Please explain new update for Profiles module

Using Jamroom


No - that's not what this means Imagine the following scenario:

- you have a user that uploads 20 songs BEFORE you place any quota limits in place
- you then set their quota limit to "10"

in this instance only the first 10 songs will now show to visitors to the profile (based on the order as set in display order). The change made it so if a visitor attempted to view a song that was hidden because of the profile limit (say song #11) they previously would get an error about the quota limits being enforced - it was the message meant to be displayed to the site owner. Now instead it just shows a "not found" page to visitors.

The second fix for hard versus soft limit was that if you had set the profile quota limit to a HARD limit (i.e. not allowed to exceed at all) profile owners would not "see" the songs above the limit to delete them.

Let me know if that helps.

disalow periods in user names

Suggestions

Sounds like a comet chat issue

You can use the Banned Items module to ban periods in user names.

Archive and Purge

Jamroom Hosting

For the Timeline, make sure the ACP -> Profiles -> Timeline -> Prune System Entries is enabled and set to something like "90" - this will prune out all the "system added" timeline entries - i.e. "so and so commented on..", etc. Timeline entries that are made by the actual user are never purged. This can usually take care of any Timeline DS issues.

As for performance profiling, you can get as involved as you want - most of them I would not recommend running on the production site.

One that you CAN turn on is set the Developer Tools -> Slow Query Log to like 2 seconds - any jrCore_list or jrCore_db_search_items calls that take longer than 2 seconds to return will be logged to the Activity Log along with information about the URL, the user and the parameters and constructed query. This can be used to spot where the "trouble spots" are and can really help narrow down your work to those areas that need it most.

Let me know if that helps.

P.S. I've sent Perrie a reply about sponsoring an archive/deleting module - Paul and I have been discussing it in chat and I think we could build something really cool.

Archive and Purge

Jamroom Hosting


Sorry if I gave that impression - of course a smaller DS will always perform better on inefficient queries so it makes sense to archive records if your use case requires lists that use a larger number of search conditions.

Archive and Purge

Jamroom Hosting


It could, but it's not that clear cut.

To be honest the calls on your site that are slowing things down are not the comments that are being listed in a specific topic - that's no problem - those will remain fast even with millions of comments. It's the lists of the type "here's the latest comments on discussions in our community profile that are related to US politics" - that requires more search conditions, which means it is going to be slower.

So if you were to attempt to do those types of lists using the Forum, you might run into the same issues.

Archive and Purge

Jamroom Hosting


Exactly. So when you start facing performance issues, the first thing to do is figure out how to be "less fancy". For example, the front page of your site right now has 13 different site builder blocks on it - 8 of them are lists. Are they all really needed? Look at Reddit - it's ONE list. If they tried to slice their data 8 different ways on every page they could never scale.

I know this isn't something you can decide on immediately, but it's something you can do over time that can really help your site scale better. Focus on reducing the number of unique listings - this gives you a better chance of having a smaller cache with a higher hit rate.

Archive and Purge

Jamroom Hosting

Note that we have sites that have more than twice as many comments as your site that are working well. What you have to do as you get bigger is start to reduce/refine the number of different ways you are presenting the data. A good example is moving to "simplepagebreak" instead of "pagebreak". Once you have thousands of pages it just doesn't make sense to have a jumper - no one is saying "I want to jump directly to page 1,267". The simple pager is much, much faster since it does not have to know exactly how many pages there are - it just adds prev/next page links.

I know on your site you are using the jrDiscussion module, which to be honest is always going to have more performance issues than our Forum module since it is a combining of 2 different datastores. However, the recent comment 2.0.0 update should have sped things up considerably for most "normal" views.

Any tool that we would make that archives comments would work correctly. Just note that I'm not sure why you would want to archive them instead of just deleting them, unless at some point you want to be able to browse through the old comments i the DB.

Audio Files not getting processed and player not loading.

Design and Skin Customization

If sox is not working correctly, your conversions are not going to work correctly. You need to be on hosting that supports all of the System Tools.