Pro Blog integrationBrowser Info Environment
Update - 10 January 2014
For anyone coming to this thread, the posts below lead through a process of building and filtering a Magic Data expression for Uber List, finding out that the filter process was a not fast enough when there was a very big list to filter, and adding a couple of new symbols to provide lightning fast listing and filtering for such cases.
On the way there were a few catches, like text strings not matching because the search indexing string was in the database without being trimmed.
I have a client with a site where users can purchase a membership. That membership purchase creates a user profile page for the member. The members submit news to the site admin to post into the blog section. Each blog entry will have a category attribute tied to it with the same name as the Business Name user attribute. I'd like to sort the blog posts by the users' categories on their profile pages.
For instance, Sam's Butcher Shop's profile page would show only blog posts with the category, "Sam's Butcher Shop".
I've read a bit of the documentation on this and it seems like it may work. Thoughts?
1. Make the list of posts. Magic data can list pages of a type, then filter that list by matching the business name attribute to a user profile attribute (or even a user name).
2. Format the list for display. Here you have a number of options:
2a. Build the list output as html directly using Magic Data.
2b. Use Uber List (which also incorporates 1)
2c. Build a template for the blog list block that gets its list of posts from a magic data expression.
If I were doing this, 2b is the solution I would use. Its the sort of combined list and formatting requirement that Uber List excels at.
'blog' AS_PAGE LIST_PAGES 10 FILTER_LIST ATTRIBUTE business_name END_FILTER
I need to make the list filter on the business_name being equal to the blog category name. I didn't see a symbol for the blog category.
As a development strategy, have a look at
This is not your requirement, but it shows the process of building and testing parts before adding them together.
The Magic Data below is only briefly tested, so you should adopt the same strategy and test the individual parts in the symbol tester before assembling them in the uber list block.
PROFILE ATTRIBUTE 'business_name' SAVE 'bus_nm' 'blog' AS_PAGE LIST_PAGES 10 APPLY_EACH LIST_PAGES 12 END_ON_NULL REDUCE_LIST MERGE_INTO 'months' END_APPLY_EACH 'months' RESTORE APPLY_EACH LIST_PAGES 100 END_ON_NULL REDUCE_LIST MERGE_INTO 'posts' END_APPLY_EACH 'posts' RESTORE FILTER_LIST ATTRIBUTE 'blog_category' EQ ( 'bus_nm' RETRIEVE ) END_FILTER
The first line retrieves the Business Name attribute from the profiled user and saves it for convenience. When testing and developing in the symbol tester, you may want to swap PROFILE to USER and then back again when ready because PROFILE only works reliably when it is used on a /profile/ page.
USER ATTRIBUTE 'business_name' SAVE 'bus_nm'
Line 2 you already have. But ProBlog has a hierarchical structure and LIST_PAGES only list those immediately below, so you will only get lists of years, not of posts. The solution is the further lists to list down within each, first to months, then to individual posts.
END_ON_NULL - quits early if a list is empty
REDUCE_LIST - removes empty and duplicate items from a list
MERGE_INTO - accumulates lists into a memory ('months' or 'posts').
The key part is the filter condition, where we take the 'blog_category' attribute of each listed post and compare it to the previously saved 'bus_nm'. Note the parenthesis to ensure we are comparing to the actual retrieved value and not the text of the symbol.
As noted, you should develop and test each fragment then assemble. For real use you may want more than 10 at each level of the list, such as allowing for 12 months in a year. You may also need to check that the attribute handles are correct.
I do occasionally get this error:
An unexpected error occurred. Unable to get permission key for write< Back to Home
Not sure what it means though.
This is a general limitation of the c5 validation key mechanism.
USER 95 ATTRIBUTE 'business_name' SAVE 'bus_nm' 'blog' AS_PAGE LIST_PAGES 10 APPLY_EACH LIST_PAGES 12 END_ON_NULL REDUCE_LIST MERGE_INTO 'months' END_APPLY_EACH 'months' RESTORE APPLY_EACH LIST_PAGES 100 END_ON_NULL REDUCE_LIST MERGE_INTO 'posts' END_APPLY_EACH 'posts' RESTORE FILTER_LIST ATTRIBUTE 'blog_category' EQ ( 'bus_nm' RETRIEVE ) END_FILTER
Any other user ID I place in there always retrieves a null result.
I tested a direct pull to make sure I had the user ID correct and was able to pull the business name from the user's attributes as well as pull the blog posts with the same category name.
data1 SYMBOL param1 param2
So to specify a user by ID you do
95 AS_USER ATTRIBUTE 'business_name'
Or in the symbol tester, use the link below the symbol entry field to set the context for the 'current user' and USER will return that user ID.
USER ATTRIBUTE 'business_name'
Though remember that on a profile page to get a user according to the profile you need to edit that to:
PROFILE ATTRIBUTE 'business_name'
With Uber List now released I suspect multiple level lists could become a common requirement, so I will look into extending the capability of LIST_PAGES for multiple levels or creating a new multi-level page listing symbol.
PROFILE ATTRIBUTE 'business_name' SAVE 'bus_nm' 'blog' AS_PAGE LIST_PAGES 100 -3 FILTER_LIST ATTRIBUTE 'blog_category' EQ ( 'bus_nm' RETRIEVE ) END_FILTER
There may also be some bulk attribute viewing addons similar to the bulk seo, but for attributes.
You can use Page Search and under the advanced options, add the blog_category attribute to the columns shown.
'blog' AS_PAGE LIST_PAGES 100 -3 APPLY_EACH SAVE m1 PAGE_NAME . ' : ' . ( m1 RESTORE ATTRIBUTE 'blog_category' ) END_APPLY_EACH HTML_OL
I've posted in the Pro Blog forum about the post categories. I'm wondering if there is a way to re-index the blog posts somehow. I see in the results that there are lots of posts within categories, but some of those profile pages still show up with no results.
Another possibility could be that you need to give the LIST_PAGES a big enough limit to list all the possible pages that are relevant before you then begin filtering them. So while there may only be a few results of interest, you need to start by listing all blog entries before reducing by the attribute match to just those results.
As a check, in the symbol tester try:
'blog' AS_PAGE LIST_PAGES 100 -3 FILTER_LIST ATTRIBUTE 'blog_category' END_FILTER_LIST APPLY_EACH SAVE m1 PAGE_LINK . ' : ' . ( m1 RESTORE ATTRIBUTE 'blog_category' ) END_APPLY_EACH HTML_OL
This will list all posts that have a blog_category attribute, whatever its value is.
The equivalent for users would be
'Business Users Group Name' AS_GROUP LIST_USERS 100 FILTER_LIST ATTRIBUTE 'business_name' END_FILTER_LIST APPLY_EACH SAVE m2 USERNAME . ' : ' . ( m2 RESTORE ATTRIBUTE 'business_name' ) END_APPLY_EACH HTML_OL
As a diagnostic, the above 2 expressions will give you 2 lists:
a) A list of blog posts with categories
b) A list of users with a business name attribute
Between them, the above should tell you if you have the basic data necessary to extract the lists.
I have noticed there is a bit of a lag in some of the queries before they post. Is there a way to speed it up?
The overhead of the diagnostic trace is not applicable when Magic Data expressions are used in the wild (unless you opt to log it).
I have another Magic Data extension in the PRB 'Magic Data Developer' that is a compendium of developer resources. Amongst the further symbols are some for benchmarking and for disabling the trace in the symbol tester(so the benchmarks are accurate!).
With Uber List, the MD expression to create the list is actually evaluated pretty fast, fractions of a second for some quite complex lists, and the built in cache can make that almost instant.
Where it can slow down is on the complexity of the stack rendered for each list item. If that is kept as simple as a typical page list - title and description - then speed is only slightly slower than a traditional page list block. If the stack is complex with lots of content and much formatting, time to show then extends proportional to the number of items in the list. On my roadmap is lazy/background loading of listed items after the first page - as is used in the best image gallery addons.
Can you take a look and see what you think? I'm using the MD/UL on the individual user page to pull in the blog. You can click through from the link below to see the load time I'm referring to.
The delay is certainly nothing to do with the rendering of individual Uber List items, because the links I have clicked had only 0 or 1 items to show!
( 1 item for The Rocket Inn:http://jrbrinkman.com/index.php/profile/61/... )
So the question is whether the time taken stems from evaluating the list expression or from the page itself. The time I am seeing is similar to that of showing an individual item page in the news (though individual blog items render quickly), so it could be a page/attribute complexity issue within that area of the site and not something Magic Data or Uber List can control.
Are there any entries in the concrete5 log relating to this?
Some tests to help narrow the problem down:
1. What is the speed like showing profile pages without any Uber List block? Perhaps with a content block or stack with some dummy content in its place.
2. What happens if you run similar Magic Data to create a list directly in an html block on a test page (ie not in a profile page and not within Uber List)? Such as:
(You will need to assign the html block a magic data template).
3. What is the speed like if you run the same Magic Data from the dashboard symbol tester?
The above 3 tests will confirm if this is related to profile pages generally or to showing the list in profile pages or to the list generating expression directly.
Also, please double check that 'Enable logging of token symbol evaluation' is not checked in the dashboard page: 'Magic Data - Symbols Settings'.
I also tried with the Magic Data pulling in something simple, i.e. the page name and it still lags just a little, just not as much as when I pull in the page name, truncated content and a link. When I run the query from the dashboard tester, it has a bit of a lag, again, not as much as the actual profile page, but a little bit. If I run the test on just one record, then it's very snappy. I think there is something to be said about the page attributes possibly slowing the page down a bit also.
I haven't had the logging enabled from the get-go. Figured it would start to pile up entries as I tested, etc.
Is the jrbrinkman.com site a development site? Could you give me admin access (by PM, not on this open forum) to have a look and run some experiments myself?
If so, I would like to install the MD developer extension so I can take some benchmarks (I would send you a zip of the package for that to install by ftp)
I'm PMing you the login info.
Before updating Uber List, you must first update Magic Data and Magic Data Symbols because Uber List requires the latest versions of both.
'blog' LIST_ALL_PAGES_WITH_FILTER 'blog_category' ( PROFILE ATTRIBUTE 'business_name' TRIM ) 100
The first parameter is the attribute to filter on. Second parameter - here expanded within the parenthesis - is the value to match against. Third parameter is the maximum number of pages to list.
Because the filtering is now integrated within the listing, the maximum number only needs to be big enough for the posts by that business, not for all possible posts.
AS_PAGE LIST_PAGES 100 -3
SET 'blog' AS_PAGE LIST_ALL_PAGES_WITH_FILTER 'blog_category' ( PROFILE ATTRIBUTE 'business_name' TRIM ) 100
For instance, this page should have several posts listed -http://jrbrinkman.com/index.php/profile/152/...
Will have a column:
In that column should be the names of the various businesses marked against each blog page indexed.
The search index values for the blog_category attributes are entered in the database with a new line before and after the value (not sure if this will show here), for example:
\nHalf Pint Concepts\n
Within LIST_ALL_PAGES_WITH_FILTER, its only possible to trim the comparison value, not the blog_category attribute value, hence the comparison is always failing.
It may be possible to get round this with some adjustments of the SQL the core search class generates.
As an alternative solution, I have attached a revised symbol LIST_ALL_PAGES_WITH_FILTER_CONTAINING which implements a containing match. To use it, please FTP and rename the attached file into:
I have hacked one of my databases to have data with a similar \n issue to yours and it tests out OK for me.
SET 'blog' AS_PAGE LIST_ALL_PAGES_WITH_FILTER_CONTAINING 'blog_category' ( PROFILE ATTRIBUTE 'business_name' TRIM ) 100
Because it implements a containing match, it could return false positives if you have similar business names where one name contains another. If you find that a problem, you will need to follow the above with the FILTER_LIST ... END_FILTER used before to remove false positives from the (short) result list.
Let me know how you get on and I will add the symbol to Uber List and release another upgrade.
I'll have to get back to you when I figure this issue out.
- Created a working list example in the dashboard symbol tester. To be safe, I also added the secondary filter I mentioned above to remove any false positive results.
- Put that list example into an Uber List block on a test page at
- Then inserted the list condition part into the Uber List block on profile pages.
On the profile pages I have visited so far, it appears to be both listing posts accurately and fast. However, I have only tested 10 or so pages.
The expression in the dashboard symbol tester is
And the expression on the profile pages is:
Looking at the post, it appears it may have been wrongly categorised.
Rooted in Family
Normal 0 MicrosoftInternetExplorer4 more.