I have a view that pulls in feed items (from various "Owner feeds" to use the feeds module lingo), then sorts them by date (very important). The owner feed has a CCK field for the type of feed (Twitter, Blog, etc.) and a CCK field theoretically to limit the number of feed items displayed in the view. (The reason for the limit is that Twitter dominates, but we want some blogs, etc., so I don't want to have to show 100 tweets before displaying my first blog.)
I'm guessing some sort of Views hook code is in order, but I'm not sure which one. Perhaps the hook that allows direct modification of the query...
Note that the Owner feed nid is being pulled into the view via a Relationship.
Thanks in advance!
Using the Arguments field in the view, you could first select the node type, then node post date.
In this way you could give priority to the blog type, before sorting by date.
You could also consider building two Views, for instance the top 5 blog items and the top 20 Twitter feeds...
Related
So I have created a page type, for content entry. The first part, 24 fields, sets up some headings and boolean fields that tell whether certain information and or buttons will be displayed on the page. This works fine and I can customize the input form just the way we want it. But the issue is how to now link in some one to many relationships. For instance alternate redirect urls, multiple content paragraphs. The idea is to have the same entry form for products as the users are currently using, the one to many escapes me. I am using the MVC dev end. I have created custom modules and associated web controls, but cannot figure how to add them to the page type layout.
Thanks in advance.
For the module tables to link to page types you need a cross-reference table. This table would hold say a GUID from the page type as well as a GUID from the module table. How you link the page type and module record could be done on the page type (while this would be harder) OR you could create a custom UI module which would allow users to view the linking table and add or remove records. This would be a listing of all the module table records and then allow you to select one module record and see or add many links to it.
Then in your page display, you simply do a custom query to that cross-reference table and join in the module table to get the data you need.
There are many approaches with pros and cons for each.
You can use Related Pages to relate to other pages that contain your content (such as a Page that contains paragraph information). My Relationships Extended Module can help with that.
You can use the content tree to store relationships, putting multiple items below the page and using the NodeAliasPath to find children of your certain page types (DocumentHelper.GetDocuments("My.PageType").Path(YourParent.NodeAliasPath+"/%"))
You can also use a multiple-selector, storing a guid or codename in a comma separated list on a single field (not greatest but it can get it done).
You can also create your own custom binding classes through the Modules, although you will need to make sure to configure things properly with the ObjectTypeInfo so it is handled properly in Kentico. Again the Relationships Extended module can aid in creating interfaces to maintain that.
See RelationshipsExtended
And also My Blog on this topic
And a presentation on different data modeling with pros and cons.
I have a custom page type for employees, and one of the fields is Location. I want to show/filter only employees in "San Jose" or "San Francisco" and used this WHERE condition below but it didn't work. Apparently, I missed something very basic. Could you help?
Location LIKE '%San%';
I did another test, where instead of page type, I used custom table with the exact field names and was able to filter using the same statement. On a related note, I'm new to Kentico and exploring which is more suitable for creating/maintaining a list of about 100 employees - Page Types or Custom Tables - with the ability to filter by department, location etc. Appreciated your input here as well. Best!
If you're adding the WHERE condition into a standard Kentico repeater or other data source, the syntax looks right except you do not need the semicolon ";".
You'll also want to double check the field name, and if you are limiting your query to certain columns (as is best practice especially for larger data sets) and be sure the field you are filtering on is being selected.
Regarding the management of your employee list, either method you've described will work. In that scenario it typically depends on who will be editing the content, and how frequently. It is more editor-friendly, in my opinion, to add those documents into the content tree. This also gives you quicker control over the order, and keeps it similar to how other content on the site is maintained. I also like to set up folders or other parent page types as categories if needed, so the documents can be dragged and dropped between them and it sets up a visual taxonomy that isn't possible if it's all stored in a table. Storing items in the tree also allows for workflow and versioning, as well as more granular control over permissions/access, if this is important to you.
It's awesome that you are thinking about how to best store your data in advance. There many factors to consider such as overall number of records, number of columns, the fact whether you need to use workflow, versioning, preview etc..
The best source of information regarding this would be this article which summarizes all options you have and gives clear explanations of which to use in which scenario.
And to your original question - What components are you using to display the data? Is the repeater? If so, can you make sure to set the Page types property to match the page type you are displaying? If the page types is not configured, Kentico will not load any custom fields because it doesn't know from which table it should load the data from.
Additionally make sure to either include the "Location" field in the Columns property or leave the columns blank (not recommended because then Kentico loads all columns which is like 200. when you count all from CMS_Document, CMS_Tree etc..)
Below is the framework that I use to debug whenever I wish to add a repeater and is facing some problem.
First get all the columns instead of accessing limited columns. Fetching all columns will make sure that I don't have any problem retrieving data.
If I am missing any particular column information name, then I would double check the column name.
I verify this by firing up SQL server management studio and access data from page type table or custom table.
If access to SQL server is not available(generally in Azure hosted solutions with restrictive access to DB), I would enable SQL debug from the settings and see what query repeater is generating to see if it is correct.
Currently, the site search will search all of the skus of the items marked as being visible in search. This is all well and good.
The problem arises when the customer knows a sku of the individual child item. So, let's say a product comes in both a 20 foot and 25 foot variation. We would put those into a configurable product and have a single product page where a customer could then choose which of those two lengths.
What happens is, a customer invariably knows that the sku of the 20 ft variation is RDB-20, while the other is RDB-25. A search for RDB-25 then, comes back with no results since the simple product is not visible in search - it doesn't realize there is a match.
How do I get the search to search an item with visibility "Not Visible Individually", when it's parent is visible in search?
The desired effect is that, if a child SKU is searched for, the parent should show up in the results.
There really is no good way of doing it without extending the default search, but at that point you might as well look for other options.
Here's a workaround that might be doable depending on how you manage your products and it worked for me until I moved on from the default search.
Rather than altering the search, try adding an attribute to all products and make it hidden concatenating all the skus into this field. The search should find the text attribute and show the configurable.
Its a bit of a workaround but works for me.
This is untested, but I did a bit of perusing in our attributes and I think I found something that might help.
Currently since our child products don't show up in our search, we have the parent populate with the children product's attributes.
However, things like brand, taxable amount, description, populate for every child product while our SKU does not.
The only difference I can see between the two attributes is under manage attributes -> click on attribute -> and then under properties go to frontend properties and select
Use In Search Results Layered Navigation: YES
Used in Product Listing: YES
Use In Layered Navigation: Filterable (with results)
I'm not sure which of these do what, but in the population of the fulltext search data table, somewhere it is being told to populate for the children and I believe that the admin panel is where.
I hope this helps!
I have a profile weblog that contains all our users details (fields seperate from the membership).
These users can submit application forms with the use of a SAEF (stand alone entry form), which will be stored in an applications weblog. Inside this applications weblog, I have a relationship field which assigns a profile to an application.
Inside this application, radio buttons are contained to allow an admin to change the status of that application (an example, a judge views an application for Joe Bloggs and sets this application to “winner”).
What I essentially need to do is filter out all the profiles that have not been set to a number of status’. So if I apply for an application and the judge is yet to view this application, my profile should not appear in the search results. My idea of this is that I would somehow have to intertwine search results with a reverse related entry tag, and as my knowledge of the search module is limited I am at a complete loss if this is even possible.
As you can see, not only do I need to search by custom field, but the profiles that will be displayed should be determined on custom fields contained in the application entry.
I would suggest using the "status" option instead of the radio custom field.
Why? Because you can accomplish the same thing you want to do with the radio field and you can set what entries you want to return in your search results.
For example, you have a status group called: "Application", which is assigned to the that weblog/channel
Within the status group, you will have three options: Pending (waiting to be looked at), Loser (judge sets it to this because it is not a winner, or just as pending), Winner (judge considers that application a winner).
Then in the search tag, you would set what statuses it will return in the search results
so if you want to only return applications/profiles that were marked winner, you would set the status="status_id" (this will be the id of "Winner" status)
I want to create a view where all 5 of my taxonomy terms are displayed and it then displays the latest node published but this is limited by 1. For Example:
Tax Term 1
Latest node published
Tax Term 2
Latest node published
etc etc
Currently I'm grouping by taxonomy term so it's displaying all nodes published then sorted by published date desc. I can't quite figure out how to limit the nodes to only show one item per taxonomy term.
Any help would be greatly appreciated.
This is possible with Views 3. I've tested this on D7, but should work on D6 also.
Add a new view of type - Taxonomy terms
Add relationship - Taxonomy term: Representative node
Other - Use aggregation: Yes
Add field - Content: Title. Change Aggregation settings to Group results together
It's not great if you have a lot of nodes, but I've done this in other cases by using a filter for "Promoted to front page" - then you simple make sure you only promote one node at a time.
I'd suggest to use a combination of panels ans views.
First, create a (or use the default) view for nodes which takes a taxonomy term as argument. Second, create a panels page containing five regions. Each region is to be filled with a view (in fact it's going to be the same view from step one, but with different arguments). Within panels ui you can restrict the number of shown entries of each view, set this value to one to have only one article be shown per term.
Panels: http://drupal.org/project/panels
Views: http://drupal.org/project/views
I'd recommend checking out the Views Group By module.
http://drupal.org/node/389230
The tutorial listed above actually describes almost exactly what you are trying to do.