source: trunk/plugins/ImageManager/backend.php @ 1239

Last change on this file since 1239 was 1192, checked in by gogo, 11 years ago

Discussion in ticket #1478

Creating Sub Classes

Addition of method Xinha.extend. This method provides a means for more "classical" sub classing within javascript. Short story,

    var Vehicle = function() { }
    Vehicle.prototype.horn = function() { alert('Toot'); }
    var Car = function()
	{; // If you want to call it.
    Xinha.extend(Car, Vehicle);
    Car.prototype.horn = function()
		alert('Toot');;  // If you want to call it.

remember the "call" method of javascript is .call(<on-this-object>, arg, arg, arg ..) and that you can also use the "apply" method to pass in arguments as an array which is .apply(<on this object>, [arg, arg, arg]), and that the arguments to your method are in the "arguments" array.

Dialog Modification

Split out the setting of the localizer from the translation of HTML in source:trunk/modules/Dialogs/XinhaDialog.js by introducing a new method Xinha.Dialog::setLocalizer(), Xinha.Dialog::translateHtml() remains compatible, the localizer is optional to it.

.htaccess Security

Further additions to the .htaccess files for the demo_images in ExtendedFileManager? and ImageManager?. I think we should give consideration to just deleting these folders totally, over the last year I've had a number of instances of people coming to me with these folders filled with various malware.

File-Picker on arbitrary fields outside Xinha (ExtendedFileManager?)

Addition of a source:trunk/plugins/ExtendedFileManager/file-picker.js hijacking of the ExtendedFileManager? in the same manner as the existing source:trunk/plugins/ImageManager/image-picker.js within ImageManager?. I'm putting this n there incase somebody finds it useful, but it may need some work as I don't use it myself any more. I am likely to come up with a way to replace both ExtendedFileManager? and ImageManager? with the "Mootools FileManager", this is a very nice file manager with a similar dialog "look" to our new dialogs, and the very VERY important bonus of it being easy to upload multiple files at once with a progress indicator (using a hidden flash component to do the hard work).

ImageManager? to use hspace and vspace attributes instead of margin.

The addition of a config option to ImageManager? "UseHSpaceVSpace" which swaps out the "margin" settings for the hspace and vspace attributes. The reason for this apparent "old fashioned-ness" is that margin is less reliably honoured when the HTML is put into an email.

YouTube and Flickr added to the ImageManager?

The addition of additional data sources (aka backends or choosers) to ImageManager?, specifically "YouTube" and "Flickr".

When one or both is enabled the user can use a selector in the image manager popup to choose from images on the local server, or search for videos on YouTube, or images on Flickr.

YouTube is enabled by setting $IMConfig['YouTube'] = TRUE; when the user selects a video the large format video still is inserted into the Xinha area, with extra information on the query string.

Flickr is enabled by setting $IMConfig['Flickr']['Key'] = 'your flickr api key here';, when the user selects an image, the image is inserted into the Xinha area.

For videos especially there needs to be some extra processing to turn that into a video when the end user sees this HTML, this is done by the "smart-image.js" script in combination with the (included) swfobject. In short, on the page WHERE YOU USE THE HTML (not where you are running Xinha to edit it) you will put this

   <script type="text/javascript" src="/path/to/xinha/plugins/ImageManager/smart-image.js"></script>
   <body onload="SmartImages.replace_all();">

it will replace the still image with the video (provided javascript is on).

Smart-image will also add a little hover attribution to Flickr sourced images (ie, hover over the image an attribution link appears). If you are going to use the Flickr source, then you must make sure you are legally permitted to do so, for one, your site can not be commercial. I've provided you with the tools, just try not to shoot yourself.

New Dialog Types

Added a new Dialog type "DetachedDialog?". This "faked" dialog extends the Xinha.Dialog and is a "drop in" replacement for it, the difference is the DetachedDialog? is not associated to any instance of Xinha. No Xinha needs to be instantiated for a "plugin" to use a DetachedDialog?. Where this is useful is in leveraging off plugins to provide functionality outside of Xinha, see link-picker.js below (in Linker).

Also added a new Dialog type "DivDialog?". Similar to the DetachedDialog?, except the dialog HTML is written directly into an html element supplied to the dialog. The use of this is similar to the above, providing a means for getting a plugin "away" from Xinha to provide it's services for other things. This Dialog may need some work since it was written before the new Xinha.Dialog was created, in brief test it worked mostly. Worth keeping around as it's a pretty simple example of how a new Dialog type can be constructed by extending the existing one.

Added a "Link Picker" to leverage the Linker plugin for providing a "Browse" button next to normal input fields in order to select a link which is written into the field.

This is the initial usage of the DetachedDialog?, the basic usage of this is described in the comments in that file source:trunk/plugins/Linker/link-picker.js

Hid all dotfiles from the Linker scanner, the linker shouldn't be showing "hidden" files.

CSS fix to dTree in linker, just to make sure it's styles were not getting clobbered.

Stylist Duplicate Stylesheet Fix

Stop the Stylist from possibly adding a duplicate stylesheet into pageStyleSheets, this was creating a subtle problem in certain circumstances.

New Plugin: WysiwygWrap?

Added a new plugin WysiwygWrap, basically this wraps the content of your Xinha with some specific elements you tell it, when in Wysiwyg mode, and strips them out again when you go back to code (or submit). The idea is to make it so that, combined with an appropriate pageStyleSheet(s) you can more easily simulate in Xinha what it will "look like" when that HTML is "published" wherever it's getting published.

It takes a simple configuration of xinha.config.WysiwygWrap = { elements: [ list of the ancestor elements to insert, in order top down ] }

  xinha.config.WysiwygWrap = { elements: ['div#outer', 'div.inner'] }

will produce this in your Xinha Wysiwyg mode html

	<div id="outer">
		<div class="inner">
			** Original Xinha Content For Editing Here **

so your pageStyleSheet would just make nice CSS for those outer and inner to make the html in the Wysiwyg mode look closer to how it would look "on the site".

In practice, I'm not sure this works that well, it seemed a good idea at the time, but it can be a bit fragile.

  • Property svn:keywords set to LastChangedDate LastChangedRevision LastChangedBy HeadURL Id
File size: 4.0 KB
3* Unified backend for ImageManager
5* Image Manager was originally developed by:
6*   Xiang Wei Zhuo, email: xiangweizhuo(at) Wei Shou.
8* Unified backend sponsored by DTLink Software,
9* Implementation by Yermo Lamers,
11* (c) DTLink, LLC 2005.
12* Distributed under the same terms as HTMLArea itself.
13* This notice MUST stay intact for use (see license.txt).
17* Instead of using separate URL's for each function, ImageManager now
18* routes all requests to the server through this single, replaceable,
19* entry point. backend.php expects at least two URL variable parameters:
21* __plugin=ImageManager   for future expansion; identify the plugin being requested.
22* __function=thumbs|images|editorFrame|editor|manager  function being called.
24* Having a single entry point that strictly adheres to a defined interface will
25* make the backend code much easier to maintain and expand. It will make it easier
26* on integrators, not to mention it'll make it easier to have separate
27* implementations of the backend in different languages (Perl, Python, ASP, etc.)
29* @see
32// Strip slashes if MQGPC is on
36  $to_clean = array(&$_GET, &$_POST, &$_REQUEST, &$_COOKIE);
37  while(count($to_clean))
38  {
39    $cleaning =& $to_clean[array_pop($junk = array_keys($to_clean))];
40    unset($to_clean[array_pop($junk = array_keys($to_clean))]);
41    foreach(array_keys($cleaning) as $k)
42    {
43      if(is_array($cleaning[$k]))
44      {
45        $to_clean[] =& $cleaning[$k];
46      }
47      else
48      {
49        $cleaning[$k] = stripslashes($cleaning[$k]);
50      }
51    }
52  }
56* ImageManager configuration
62* debug message library
65include_once( "ddt.php" );
67// uncomment to turn on debugging
68// _ddtOn();
70_ddt( __FILE__, __LINE__, "backend.php: top with query '" . $_SERVER["PHP_SELF"] . "' string '" . $_SERVER["QUERY_STRING"] . "'" );
72$formVars = empty($_POST) ? $_GET : $_POST;
74// make sure the request is for us (this gives us the ability to eventually organize
75// a backend event handler system) For an include file the return doesn't make alot of
76// sense but eventually we'll want to turn all of this into at least functions
77// separating out all the presentation HTML from the logic. (Right now all the HTML
78// used by ImageManager is in the same files as the PHP code ...)
80if ( @$formVars[ "__plugin" ] != "ImageManager" )
81        {
82        // not for us.
84        _ddt( __FILE__, __LINE__, "request was not for us" );
86        return true;
87        }
89// so we don't have to re-engineer the entire thing right now, since it's probably
90// going to get rewritten anyway, we just include the correct file based on the
91// function request.
93_ddt( __FILE__, __LINE__, "backend.php(): handling function '" . $formVars[ "__function" ] . "' base_dir is '" . $IMConfig["base_dir"] . "'" );
95switch ( @$formVars[ "__function" ] )
96        {
98        case "editor":
100                include_once( $IMConfig['base_dir'] . "/editor.php" );
101                exit();
103                break;
105        case "editorFrame":
107                include_once( $IMConfig['base_dir'] . "/editorFrame.php" );
108                exit();
110                break;
112        case "manager":
114                _ddt( __FILE__, __LINE__, "including '" . $IMConfig['base_dir'] . "/manager.php" );
116                include_once( $IMConfig['base_dir'] . "/manager.php" );
117                exit();
119                break;
121        case "images":
123                include_once( $IMConfig['base_dir'] . "/images.php" );
124                exit();
126                break;
128        case "thumbs":
130                include_once( $IMConfig['base_dir'] . "/thumbs.php" );
131                exit();
133                break;
135        case "resizer":
137                include_once( $IMConfig['base_dir'] . "/resizer.php" );
138                exit();
140                break;
143        case "youtube":
145                include_once( $IMConfig['base_dir'] . "/youtube.php" );
146                exit();
148                break;
151        case "flickr":
153                include_once( $IMConfig['base_dir'] . "/flickr.php" );
154                exit();
156                break;
158        default:
160                _ddt( __FILE__, __LINE__, "function request not supported" );
161                _error( __FILE__, __LINE__, "function request not supported" );
163                break;
165        }       // end of switch.
167return false ;
169// END
Note: See TracBrowser for help on using the repository browser.