Customer Portal

Get Involved. Join the Conversation.


  • domn

    Wow, thank you so much for pointing that out. It was indeed the overflow option causing the problem. Of course this opened up a few other problems in 7 but at least I know the root cause.


    Thanks again.  

  • Leif Wickland


    Thanks for providing me with your code. I managed to get it running on an internal site. The problem is in Input.css, which contains a rule like:



    tr.FormField td.FieldContent input[type=text], tr.FormField td.FieldContent textarea







    That CSS was replace with the following in a bug fix which appeared in Feb '09



    tr.FormField td.FieldContent input[type=text], tr.FormField td.FieldContent textarea






    When I was working with your site, just removing the "display:block" bit appeared to be sufficient, but I suspect there's a reason for the width change, too.


    That change is documented in the Feb '09 release notes on page 22 of the upgrade impact presentation.  There's no reason you would've seen that, but I thought I'd mention it so that other folks who encounter this might know where to look to find such solutions in the future.


    Please let me know if that change doesn't fix the problem for you.

  • Leif Wickland
    I'm really glad that you figured it out. Thanks for posting what you found that fixed the problem.

    Please let us know if you have further questions.
  • Leif Wickland

    I think that's a good solution that should work well.

    Thanks for posting what you found.
  • awoolson

    An AHA! moment.

    I had commented out "#rn_sidebar .rn_wrap - Comment out background image" and when I un-commented it out (or put it back in actually, ) everything seems to line up correctly - and the width of the announement box seems to have changed appropriately.


    Thanks so much for your help!!!

  • awoolson

    I really appreciate the help, but I still must be doing soemthing wrong.... after following you suggestion below, the home page looks like this in the development site (see image at bottom). the Announcement text is all the way at the bottom. Any idea where I went wrong?


    Thank you again for all your help and suggestions.




    11685RN.jpeg (139KB)
  • January Fredericks

    So I think we got this to work.


    We ended up going for the report approach. We updated the end user report to map_category  not equals (include no value) no value. We were already using a custom report for this, so it was just an edit.The search widget was already referencing this report. 


    Thanks so much for all your help. I hope I'm not speaking too soon. :)



  • Leif Wickland

    Thanks for the reply.

    I think this post basically explains what's going on. After the user clicks a link containing "/c/***", subsequent requests try to be smart (anticipating the behavior that the other poster requested) by reading parameters out of the current URL to be included in the next search. If you don't want the category filter to apply to the keyword search, you need to remove the "/c/***" bit from the URL. Two places you could make that change are:

    1. Subscribe to the on_before_ajax_request JavaScript event and modify the URL in the desired cases.
    2. Subscribe to the search button's click event. When the button is clicked, get the value of the search box and redirect based on it. For example, redirect to /app/answers/list/kw/theUserSearchTerm.

    I believe the Customer Portal documentation should have an example for subscribing to on_before_ajax_request.
  • Ernie Turner

    Both of these problems are created by a custom CSS rule that you added to the rn_basic.css stylesheet. At the top I see this rule



    body,div,dl,dt,dd,ul,ol,li,h1,h2,h3,h4,h5,h6,pre,code,form,fieldset,legend,input,textarea,p,blockquote,th,td{ margin:0; padding:0; overflow: hidden; }


    The 'overflow:hidden' rule is not in our standard stylesheet and is what is causing both of these issues in IE7. If I remove that rule through the use of the IE Developer Tools, both problems go away. For both issues the problem is around a DIV with the class name 'FieldInfobox', so maybe create an exception for DIV elements with that class name.


    All widgets should work across browsers, its part of the testing that is done on every release. However, as you've seen here, it is pretty simple to make them uncompatible with general CSS rules.



  • January Fredericks

    Hi Leif,

    That is exactly correct!

  • Ernie Turner
    I would suggest creating a custom widget for this instead of a PHP include. Its basically the same thing, but it will probably make the usage easier since you will be able to use widget tags instead of PHP. The standard/composite/MyStuffNav would be a good widget to look at since it's basically a nav bar.
  • Leif Wickland

    I'm sorry you ran into troubles when you cut over. I'm really glad Pat could help you.

    When you create a custom widget, you only have to copy the view.php. The view contains references to the other files that it will use, such as controller, JavaScript, and CSS. If you copy a standard widget view and do not modify those attributes in the <rn:meta> tag, your custom widget will continue to use the standard components beside the view.

    The files comprising the widget (e.g, view.php, controller.php, and logic.js) must have the standard names for the system to find the files. If you created widgets/custom/mine/mine.php, it would not be a widget; a view.php is required.

    A widget gets its name from the folder that its view.php is in.

    You can name custom widgets the same as a standard widget, but unfortunately there are a few complications with doing so.

    1. You cannot have two different widgets with the same controller name on a single page. For example, if you copied widgets/standard/utils/RNTLogo to widgets/custom/mine/RNTLogo, modified the custom one to use a custom controller called RNTLogo, and tried to stick both on the same page, you'd receive an error.
    2. In May '09 I've fixed a bug with the Dreamweaver extension related to this. In previous versions if two widgets used different controllers with the same name (as in my example above), all widgets using controllers with those names would get the insert widget dialog of one of those controllers.

    So, while it is possible to have custom widgets with the same name as a standard widget, it's probably not advisable until May '09.

    Please let me know if I haven't answered your questions or if my answers are unclear.
  • Leif Wickland

    Is the following the scenario you're trying to accomplish?

    1. The user goes to your home page.
    2. He selects a category.
    3. Answers in that category are displayed.
    4. He doesn't see the answer he wants.
    5. The user searches by a keyword.
    6. He should see answers matching that keyword regardless of category.
  • David Smith
    You are correct sir! Thank you, thank you! Very cool.
  • monique perkins
    It sounds like you need a custom widget that gets the category data and displays it.  There are functions to build one.  If you want to use a search widget to do so then you should set a different report_id as Leif suggested.  You will need to build a custom report that has the map_cat_hierarchy filter on it so you get the correct data to the widget and don't get an error.  Set the category widget to the new report_id.  Then when the search button is clicked the category data won't be used as part of the filtering.