We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 25663 MODX Staff
    • 12,272 Posts
    OK ... another day down, another major milestone reached: Newslisting is now behaving much more properly. The coolest new addition is that it now automatically closes open tags so it doesn’t jack your site layout with open DIV, UL or OL tags for example.

    That really doesn’t leave anything I see as worthwhile for holding up a release. There will be ongoing cleanups, but the big holdup now is strictly committing all the changes and new snippets to SVN (and any bugfixes from Raymond).
      Ryan Thrash, MODX Co-Founder
      Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
      • 18397
      • 3,250 Posts
      Ryan do you want your new ...

      Quote from: rthrash at Oct 12, 2005, 02:52 AM

      closes open tags so it doesn’t jack your site layout with open DIV, UL or OL tags for example.

      ...code in the NewsFeed snippet along with the <!-- splitter --> capeability?
        • 32963
        • 1,732 Posts
        Ryan,

        Can you package the graphics, snippets, template needed for the site?
          xWisdom
          www.xwisdomhtml.com
          The fear of the Lord is the beginning of wisdom:
          MODx Co-Founder - Create and do more with less.
          • 32963
          • 1,732 Posts
          Hi Everyone,

          TP3.3 fixes are now in SVN. Please note that there are some outstanding bugs to be fixed and the default content is not yet loaded inside the installer
            xWisdom
            www.xwisdomhtml.com
            The fear of the Lord is the beginning of wisdom:
            MODx Co-Founder - Create and do more with less.
            • 4018
            • 1,131 Posts
            One more change that needs to be made. Ryan and I have been doing a little e-mail tagging regarding the recent work on the default content. One of the things I noticed was a small problem dealing with the use of RTE’s on the frontend. The problem seemed to be that unless a width and height is expressed for the editor itself, there’s a possibility that it won’t stay within the boundaries of its div element. So...I felt it best to simply modify the RichText widget type so that the width and height is passed to the OnRichTextEditorInit event. After that, it’s just a simple matter of modifying the plugin code to assign a width and height if present (in this case, in the FCKEditor code). The change is as follows:

            In /manager/includes/tmplvars.format.inc.php
            Around line 136:

            			case "richtext":
            				$value = parseInput($value);
            				$w = $params['w']? $params['w']:'100%';
            				$h = $params['h']? $params['h']:'400px';
            				$richtexteditor = $params['edt']? $params['edt']: "";
            				$modx->regClientStartupScript("manager/media/script/bin/webelm.js");
            				$o = '<div style="position:relative; width:'.$w.'; height:'.$h.';"><textarea id="'.$id.'" name="'.$id.'" style="width:'.$w.'; height:'.$h.';">';
            				$o.= htmlspecialchars($value);
            				$o.= '</textarea></div>';
            				$replace_richtext = array($id);
            				// setup editors
            				if (!empty($replace_richtext) && !empty($richtexteditor)) {
            					// invoke OnRichTextEditorInit event
            					$evtOut = $modx->invokeEvent("OnRichTextEditorInit",
            													array(
            														editor 		=> $richtexteditor,
            														elements	=> $replace_richtext,
            														forfrontend => 1
            													));
            					if(is_array($evtOut)) $o.= implode("",$evtOut);
            				}
            				break;
            


            Change to:

            			case "richtext":
            				$value = parseInput($value);
            				$w = $params['w']? $params['w']:'100%';
            				$h = $params['h']? $params['h']:'400px';
            				$richtexteditor = $params['edt']? $params['edt']: "";
            				$modx->regClientStartupScript("manager/media/script/bin/webelm.js");
            				$o = '<div style="position:relative; width:'.$w.'; height:'.$h.';"><textarea id="'.$id.'" name="'.$id.'" style="width:'.$w.'; height:'.$h.';">';
            				$o.= htmlspecialchars($value);
            				$o.= '</textarea></div>';
            				$replace_richtext = array($id);
            				// setup editors
            				if (!empty($replace_richtext) && !empty($richtexteditor)) {
            					// invoke OnRichTextEditorInit event
            					$evtOut = $modx->invokeEvent("OnRichTextEditorInit",
            													array(
            														editor 		=> $richtexteditor,
            														elements	=> $replace_richtext,
            														forfrontend => 1,
            														width 		=> $w,
            														height		=> $h
            													));
            					if(is_array($evtOut)) $o.= implode("",$evtOut);
            				}
            				break;
            


            You can see that it’s a relatively small change...just a few additional parameters passed into the array for the OnRichTextEditorInit call. A couple of things to remember about this though...the parameters can, of course, be ignored in the plugin but you have to test the plugin to ensure that it works correctly when used as a frontend TV. Also, the width and height can be expressed with pixels (i.e. 400px). FCKEditor doesn’t like having a ’px’ on the end so it’s necessary to make sure and strip it out if it’s present in the variable. I’ve also attached the updated code for FCKEditor that has a TPL file reflecting these changes. As always, make sure that the TPL file is updated.

            Another thing that was discussed was the assignment of a custom ’web user’ theme/toolbar for every RTE. FCKEditor already has this feature as part of its configuration tab. Once TP3.3 is released, I’ll make sure and update Xinha and TinyMCE to allow a similar feature.

            That’s all for now! smiley

            Jeff
              Jeff Whitfield

              "I like my coffee hot and strong, like I like my women, hot and strong... with a spoon in them."
              • 25663 MODX Staff
              • 12,272 Posts
              So does the TV control allow you to select which toolbar to use now?

                Ryan Thrash, MODX Co-Founder
                Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
                • 4018
                • 1,131 Posts
                Quote from: rthrash at Oct 13, 2005, 05:03 PM

                So does the TV control allow you to select which toolbar to use now?



                No, it just allows the developer access to the width and height parameters when developing an RTE plugin. The control over toolbars is controlled by the plugin itself. To allow selection of a toolbar or theme via a TV would require some serious ass coding. To do that, you would have to parse out the configuration parameters and add them to the widget properties. In the case of FCKEditor, the ’Web Toobar’ configuration parameter would be parsed out to allow the input of a different toolbar for any given instance of a RichText widget. This might be something to think about for a later release...might be interesting. I’ll play around some more and see what I can come up with...ya never know! Might be something easy to do. laugh
                  Jeff Whitfield

                  "I like my coffee hot and strong, like I like my women, hot and strong... with a spoon in them."
                  • 25663 MODX Staff
                  • 12,272 Posts
                  Let me rephrase: If I’ve got the advanced toolbar selected for the manager, will this use the advanced toolbar on the front end? If so, can we spec different toolbars for the front end vs the back end? Or install multiple instances with slightly different names to emulate different toolbars?

                  Just thinking through some things...
                    Ryan Thrash, MODX Co-Founder
                    Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
                    • 4018
                    • 1,131 Posts
                    Hmm...well....in the case of FCKEditor, you could always copy the code for the toolbar from the custom_config.js file in the FCKEditor directory and paste it directly into the field for the Web Toolbar configuration parameter. That’ll make it use the same exact toolbar. However, I think what you’re wanting is a drop-down menu or the like. I’ve got a simple idea on how to add something on like this. Basically we add one more parameter to the FCKEditor configuration that allows for the selection of a toolbar much in the same way that it is now...except it’s limited to the FCKEditor configuration and can’t be set by normal MODx users. That would do the trick for now.

                    I’d still like to explore the idea of parsing editor configuration parameters into a RichText widget instance. That would be cool because it would allow you to set a few different parameters like toolbars and such separately for any given TV instance. Definitely a good idea! wink
                      Jeff Whitfield

                      "I like my coffee hot and strong, like I like my women, hot and strong... with a spoon in them."
                      • 28042 ☆ A M B ☆
                      • 24,524 Posts
                      I do hope the 3.3 release isn’t going to be held up over tiny incremental "feature creep" issues. I would rather see more releases, or patches for such odds and ends.
                        Studying MODX in the desert - http://sottwell.com
                        Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
                        Join the Slack Community - http://modx.org