متن نامه هاي يك سري از پلاگين كار هاي ام تي كه در مورد پلاگين هاي ورژن 3 ام تي بحث مي كنند. حيف كه نمي شه اين همه متن رو ترجمه كرد. مطمئنا كلي نكته آموختني توشه!
There are 17 messages in this issue.
________________________________________________________________________
________________________________________________________________________
Message: 1
Date: Tue, 18 May 2004 11:25:43 -0400
From: Kevin Shay <[email protected]>
Subject: Plugin versions for MT3
Plugin developers,
If a given plugin needs to be updated (and/or can be enhanced) for
MT3, how are you planning to handle this? Do you intend to distribute
two separate versions of the plugin? Or put all the variant code in
one plugin and switch based on MT::VERSION?
I'd like to avoid maintaining two versions of 17 plugins, but I guess
putting all the code in one file would preclude the approach of
subclassing MT:
lugin in order to register it...
Also, what about version numbering for your plugins?
Any thoughts on best practices would be appreciated.
By the way, it seems you can install a copy of MT 2.661 in a separate
directory, and point it to your MT3-updated database, and it will
sort of work. You just have to put the old docs and images in a
separate mt-static directory and edit the 2.661 config file to
reflect this. Of course, you shouldn't actually use 2.661 to edit
entries, authors, etc., after upgrading, since it won't populate all
the new columns. But if you just want to tinker with templates (the
mt_template schema appears not to have changed) and test plugins
under both versions, this could come in handy.
Thanks,
--Kevin
________________________________________________________________________
________________________________________________________________________
Message: 2
Date: Tue, 18 May 2004 12:38:15 -0400
From: "Chad Everett" <[email protected]>
Subject: RE: Plugin versions for MT3
I haven't actually planned it out yet, but I'm thinking that for plugins
that care about the version, I'll 'freeze' existing plugins where they are,
and only issue new plugins (with new version numbers) for MT3. I'll
probably bump the version number to the next highest 'major' number to
indicate such a shift. Of course, if there's a bug or something it might
raise issues, but I'm pretty certain most of them are clean at the moment.
Dunno if this is a 'best practice', but like you I don't really want to
maintain separate versions. If the existing ones work, I'll leave them out
there. Then just move forward on the 'new' ones.
-----Original Message-----
From: Kevin Shay [mailto:[email protected]]
Sent: Tuesday, May 18, 2004 11:26 AM
To: [email protected]
Subject: [mt-dev] Plugin versions for MT3
Plugin developers,
If a given plugin needs to be updated (and/or can be enhanced) for
MT3, how are you planning to handle this? Do you intend to distribute
two separate versions of the plugin? Or put all the variant code in
one plugin and switch based on MT::VERSION?
I'd like to avoid maintaining two versions of 17 plugins, but I guess
putting all the code in one file would preclude the approach of
subclassing MT:lugin in order to register it...
Also, what about version numbering for your plugins?
Any thoughts on best practices would be appreciated.
[This message contained attachments]
________________________________________________________________________
________________________________________________________________________
Message: 3
Date: Tue, 18 May 2004 12:27:14 -0700
From: Ezra Cooper <[email protected]>
Subject: Re: Returning an Object from Callback?
Hi all,
Let me first explain the reasoning behind the way it works now, and
then we can talk a little bit about how it might better support what
you're trying to do.
If you're writing a plugin that creates an on-disk representation of
the object that's different from the in-memory representation--for
example, if you wanted to store it in some encoded form that was hidden
from the interface--then you have to ensure that the in-memory
representation never gets polluted with your transformations. That's
what the cloning step does for you: it gives you a database-level
object to mangle, while allowing the application to continue with an
application-level object.
Now, I understand the use case for what you're doing here: you actually
want your callback to modify the object, in both its in-memory and
on-disk forms. That sounds like a very useful case and one that we
should try to support.
So here's a proposal. What if the callback was given both the
"original" (app-level) object AND the "clone" (database-level) object.
According to your humour, then, you could modify one or both or
neither. The clone is the object that would get saved and the original
is the object that the application will continue to act upon in that
request.
Thoughts on this?
Ezra
On May 16, 2004, at 2:49 PM, Phil Ringnalda wrote:
> On 16 May 2004 20:39:54 -0000, jayseae wrote:
> > I added a log entry to the comments loop, and the value of visible
> is still
> > 1 after I've executed my pre-save callback that sets it to 0. I'm
> assuming
> > this is because the pre_save callback happens in a different scope,
> and while
> > that change is saved to the database, it's not maintained into the
> code in
> > Comments.pm. Even though it's saving 0, it's got a 1 there while
> the module
> > executes.
>
> D'oh. I had a reasonable answer, it just wasn't the right answer to
> the right question
>
> Take a look at the various save()s in lib/MT/ObjectDriver/ - they get
> the $obj, move $obj to $original, and put a clone of $obj in $obj,
> which then runs the callbacks. We don't get to touch the actual
> object, just the clone.
>
> Phil Ringnalda
>
>
[This message contained attachments]
________________________________________________________________________
________________________________________________________________________
Message: 4
Date: Tue, 18 May 2004 15:48:03 -0400
From: "Chad Everett" <[email protected]>
Subject: RE: Returning an Object from Callback?
Works for me.
-----Original Message-----
From: Ezra Cooper [mailto:[email protected]]
Sent: Tuesday, May 18, 2004 3:27 PM
To:
Subject: Re: [mt-dev] Returning an Object from Callback?
Hi all,
Let me first explain the reasoning behind the way it works now, and then we
can talk a little bit about how it might better support what you're trying
to do.
If you're writing a plugin that creates an on-disk representation of the
object that's different from the in-memory representation--for example, if
you wanted to store it in some encoded form that was hidden from the
interface--then you have to ensure that the in-memory representation never
gets polluted with your transformations. That's what the cloning step does
for you: it gives you a database-level object to mangle, while allowing the
application to continue with an application-level object.
Now, I understand the use case for what you're doing here: you actually want
your callback to modify the object, in both its in-memory and on-disk forms.
That sounds like a very useful case and one that we should try to support.
So here's a proposal. What if the callback was given both the "original"
(app-level) object AND the "clone" (database-level) object. According to
your humour, then, you could modify one or both or neither. The clone is the
object that would get saved and the original is the object that the
application will continue to act upon in that request.
Thoughts on this?
Ezra
[This message contained attachments]
________________________________________________________________________
________________________________________________________________________
Message: 5
Date: Tue, 18 May 2004 13:39:56 -0700
From: Phil Ringnalda <[email protected]>
Subject: Re: Returning an Object from Callback?
On Tue, 18 May 2004 12:27:14 -0700, Ezra Cooper <[email protected]> wrote:
> If you're writing a plugin that creates an on-disk representation of
> the object that's different from the in-memory representation--for
> example, if you wanted to store it in some encoded form that was hidden
> from the interface--then you have to ensure that the in-memory
> representation never gets polluted with your transformations. That's
> what the cloning step does for you: it gives you a database-level
> object to mangle, while allowing the application to continue with an
> application-level object.
Ah, the store-in-XHTML edit-in-Textile thing. I'm so uninterested in
learning a new markup language that I missed that completely. I
probably would have tried doing it the hard and leaky way by combining
a pre-save encoding and a post-save decoding,
> So here's a proposal. What if the callback was given both the
> "original" (app-level) object AND the "clone" (database-level) object.
> According to your humour, then, you could modify one or both or
> neither. The clone is the object that would get saved and the original
> is the object that the application will continue to act upon in that
> request.
That should actually be more useful for both cases, since the
alternate markups seem to always be leaking into other things, like
excerpts: if you know that remove_html won't clean you up for an
auto-generated excerpt, you can auto-generate your own and stick in in
the app's object for use in pinging. I like it!
Phil Ringnalda
________________________________________________________________________
________________________________________________________________________
Message: 6
Date: Wed, 19 May 2004 07:28:44 -0400
From: "Chad Everett" <[email protected]>
Subject: Implementing add_plugin_slug?
I've been trying to figure out how to get the add_plugin_slug function to
work, and have to say that I'm still stumped. I installed Tim's mt-rssfeed
to see how it worked, and couldn't seem to get that to display anything
either (though perhaps I don't have something enabled correctly).
Are there any working examples of how this is supposed to be specified?
Thanks!
---
Chad Everett
[email protected]
________________________________________________________________________
________________________________________________________________________
Message: 7
Date: Wed, 19 May 2004 14:41:20 -0000
From: "Timothy Appnel" <[email protected]>
Subject: Re: Implementing add_plugin_slug?
Somewhere along the alpha trail the add_plugin_slug method and the Plugin
API changed.
Sorry if I caused any confusion not releasing a version that worked with the
updated API.
In the "real" mt-feeds plugin I'm working on now, I'm doing this (put into
generic terms):
package MT::Foo;
use MT;
use vars qw($VERSION);
$VERSION = '1.0';
eval{ require MT:lugin };
unless ($@) {
my $about = {
name => "Foo $VERSION",
description => 'From foo with love.',
dir_name => "foo",
config_link => 'config.cgi'
};
MT->add_plugin( new MT:lugin($about) );
}
This seems to work nicely for registering the plugin if running under 3.0
(and presumably
up) while not creating errors for 2.661 users.
I read some of the earlier posts on versions and think it was right on. I
intend on going
over and updating all of my plugins. (They needed to be cleaned up any way.)
If I decide to
add 3.0 specific functionality I'll create a new major version and keep the
old version
available for MT2 users. (This is similar to what Apache did with their
process-based and
thread-based servers.) If a plugin doesn't take advantage of MT3 functions,
I'll just add the
above to optionally register it if I can.
Hope that helps.
<tim/>
________________________________________________________________________
________________________________________________________________________
Message: 8
Date: Wed, 19 May 2004 11:26:27 -0400
From: "Chad Everett" <[email protected]>
Subject: RE: Re: Implementing add_plugin_slug?
Did the trick. Thanks!
The dir_name doesn't seem to be documented either on the online tutorial or
in Plugin.pm. What does it do?
Is there any standard established for config_links? The plugins I've
developed that are executable on their own, I've always put into the MT
directory - but that doesn't have to be the case. Is there anything in mind
at this point?
-----Original Message-----
From: Timothy Appnel [mailto:[email protected]]
Sent: Wednesday, May 19, 2004 10:41 AM
To:
Subject: [mt-dev] Re: Implementing add_plugin_slug?
package MT::Foo;
use MT;
use vars qw($VERSION);
$VERSION = '1.0';
eval{ require MT:lugin };
unless ($@) {
my $about = {
name => "Foo $VERSION",
description => 'From foo with love.',
dir_name => "foo",
config_link => 'config.cgi'
};
MT->add_plugin( new MT:lugin($about) );
}
[This message contained attachments]
________________________________________________________________________
________________________________________________________________________
Message: 9
Date: Wed, 19 May 2004 15:38:51 -0000
From: "Timothy Appnel" <[email protected]>
Subject: Re: Implementing add_plugin_slug?
You'll have to forgive me because I've been at testing and disecting the
code for the past
couple of months that I've forgotten were I saw some of this.
Plugins can now have their own subdirectory in the /plugins directory. This
is because
plugins will surely begin to have multiple files with the expanded
capabilities of MT3's
plugin API. This keeps things neat and organized. So the dir_name defines to
MT what the
name of the plugins subdirectory any other related files (such as
config.cgi) are located.
That's roughly it. I suppose the best practice will be if your plugin has
more then one file
(not counting modules which should go in extlib or perhaps templates which
should go in
their own subdirectory of /tmpl) then you should include a dir_name
attribute. Otherwise
just place it in the main plugins directory with a descriptiive/unique name.
<tim/>
________________________________________________________________________
________________________________________________________________________
Message: 10
Date: Wed, 19 May 2004 11:42:49 -0400
From: "Chad Everett" <[email protected]>
Subject: SCRIPT_URL in header.tmpl
Header.tmpl holds a parameter named SCRIPT_URL, which has the script that
submitted the template. In most cases (if not all) within the UI, the value
of this parameter is 'mt.cgi'.
If I create a config_link for a plugin, let's say mt-myplugin.cgi, then when
I use header.tmpl in a template that script generates, the value of
SCRIPT_URL will be mt-myplugin.cgi. This means the links in header.tmpl
will be hosed.
Does anyone know of any way to get around this? Either by adding a method
to mt.cgi (MT::APP?) or faking out the build_page process so that it will
get mt.cgi instead of mt-myplugin.cgi?
I can hack build_page, but I'd rather not. I could build a duplicate of
build_page in my plugin (and have in the past), but that isn't as clean and
it needs to be updated whenever the 6A code gets updated. I could create my
own header template (or handle it in my plugin template), but again that
seems to duplicate effort.
Perhaps I could add in code to my plugin to handle all possible links that
might be in the UI and pass those off to the MT::APP functions? Again
kludgy, and if the parameters change or new features are added, I've got to
update the template again.
Any ideas?
---
Chad Everett
[email protected]
________________________________________________________________________
________________________________________________________________________
Message: 11
Date: Wed, 19 May 2004 17:17:28 -0000
From: "Timothy Appnel" <[email protected]>
Subject: Re: SCRIPT_URL in header.tmpl
The quick fix is to overload the uri method in MT::App. Instead of this:
sub uri { $_[0]->path . $_[0]->script }
Use this in your subclass:
sub uri { $_[0]->path . MT::ConfigMgr->instance->AdminScript }
This isn't perfect and its untested so you could still get tripped up. If
you make a call to uri
and expect your script's url this fix will cause issues. If mt.cgi is
running under https while
your script is under http is another that leapt to mind. (Really they should
run under the
same protocol. If not a little redirect magic could remedy that.) Its likely
I may overlooked
something else in my haste. If you win the developer's contest do I get a
percentage of the
prize?
What really needs to happen is that header and footer templates gets split
out. That
particular instance of SCRIPT_URL should be loaded up using the AdminScript
configuration param (or default) and a utility class created for loading up
the appropriate
data into the structure HTML::Template expects.
<tim/>
________________________________________________________________________
________________________________________________________________________
Message: 12
Date: Wed, 19 May 2004 13:30:42 -0400
From: "Chad Everett" <[email protected]>
Subject: RE: Re: SCRIPT_URL in header.tmpl
If I should happen to win something, I'm sure we can work something out.
-----Original Message-----
From: Timothy Appnel [mailto:[email protected]]
Sent: Wednesday, May 19, 2004 1:17 PM
To:
Subject: [mt-dev] Re: SCRIPT_URL in header.tmpl
If you win the developer's contest do I get a percentage of the prize?
________________________________________________________________________
________________________________________________________________________
Message: 13
Date: Wed, 19 May 2004 13:30:30 -0400
From: "Chad Everett" <[email protected]>
Subject: RE: Re: Implementing add_plugin_slug?
No forgiveness necessary, Tim.
The dir_name value doesn't seem to be used anywhere that I can find it. Is
this something that will be coming in the future? There is an 'envelope' in
Plugin.pm that looks like it is used in CMS.pm, which in turn seems as if it
may be doing the same thing you're talking about here, but I can't seem to
get it to work as I'd expect it to work. No worries for now - mostly just
curious.
Thanks again.
---
Chad Everett
[email protected]
________________________________________________________________________
________________________________________________________________________
Message: 14
Date: Wed, 19 May 2004 11:45:53 -0700
From: Ezra Cooper <[email protected]>
Subject: Re: Re: Implementing add_plugin_slug?
On May 19, 2004, at 10:30 AM, Chad Everett wrote:
> No forgiveness necessary, Tim.
>
> The dir_name value doesn't seem to be used anywhere that I can find
> it. Is
> this something that will be coming in the future? There is an
> 'envelope' in
> Plugin.pm that looks like it is used in CMS.pm, which in turn seems
> as if it
> may be doing the same thing you're talking about here, but I can't
> seem to
> get it to work as I'd expect it to work. No worries for now - mostly
> just
> curious.
Hi guys--
Thanks for the excellent explanation of the newer plugin slug
interface, Tim. To confirm that, I suggest creating a directory for
your plugin if it has more than one file.
The dir_name parameter for MT:lugin is obsolete, actually. We
realized that we could set that value automatically when loading the
plugin so you don't have to specify it. This allows you to rename your
plugin directory (the "envelope") without changing the code. You can
query an MT:lugin for its envelope by calling the envelope() method.
Ezra
________________________________________________________________________
________________________________________________________________________
Message: 15
Date: Wed, 19 May 2004 13:23:40 -0700
From: Phil Ringnalda <[email protected]>
Subject: Re: Re: Implementing add_plugin_slug?
On Wed, 19 May 2004 11:45:53 -0700, Ezra Cooper <[email protected]> wrote:
>
> The dir_name parameter for MT:lugin is obsolete, actually. We
> realized that we could set that value automatically when loading the
> plugin so you don't have to specify it. This allows you to rename your
> plugin directory (the "envelope") without changing the code. You can
> query an MT:lugin for its envelope by calling the envelope() method.
>
Just to be sure I'm not still confused:
I have one file, I put it in /plugins/simpleplugin.pl
I have two files, I put them in /plugins/fancyplugin/fancyplugin.pl
and /plugins/fancyplugin/fancyconfig.cgi?
That's where I was missing the point of the envelope, thinking that I
would put fancyplugin.pl in /plugins/ and fancyconfig.cgi in
/plugins/fancyplugin/.
Phil Ringnalda
________________________________________________________________________
________________________________________________________________________
Message: 16
Date: Wed, 19 May 2004 23:44:01 -0000
From: "tsbalaban" <[email protected]>
Subject: Adding functions accessiblr by mt.cgi
I have an options.pm with functions of mine that call CMS functions.
I want to add my function references in my "add_methods" call of my
sub init to the function references in the CMS sub init. This way
all mine and CMS functions are accessible to mt.cgi by the __mode
parameter. Would it help to make my functions global and how?
Thanks for any help.
Ted
________________________________________________________________________
________________________________________________________________________
Message: 17
Date: Wed, 19 May 2004 23:49:50 -0000
From: "tsbalaban" <[email protected]>
Subject: Adding functions accessible by mt.cgi
I have an options.pm with functions of mine that call CMS functions.
I want to add my function references in my "add_methods" call of my
sub init to the function references in the CMS sub init. This way
all mine and CMS functions are accessible to mt.cgi by the __mode
parameter. Would it help to make my functions global and how?
Thanks for any help.
Ted
There are 17 messages in this issue.
________________________________________________________________________
________________________________________________________________________
Message: 1
Date: Tue, 18 May 2004 11:25:43 -0400
From: Kevin Shay <[email protected]>
Subject: Plugin versions for MT3
Plugin developers,
If a given plugin needs to be updated (and/or can be enhanced) for
MT3, how are you planning to handle this? Do you intend to distribute
two separate versions of the plugin? Or put all the variant code in
one plugin and switch based on MT::VERSION?
I'd like to avoid maintaining two versions of 17 plugins, but I guess
putting all the code in one file would preclude the approach of
subclassing MT:
lugin in order to register it...Also, what about version numbering for your plugins?
Any thoughts on best practices would be appreciated.
By the way, it seems you can install a copy of MT 2.661 in a separate
directory, and point it to your MT3-updated database, and it will
sort of work. You just have to put the old docs and images in a
separate mt-static directory and edit the 2.661 config file to
reflect this. Of course, you shouldn't actually use 2.661 to edit
entries, authors, etc., after upgrading, since it won't populate all
the new columns. But if you just want to tinker with templates (the
mt_template schema appears not to have changed) and test plugins
under both versions, this could come in handy.
Thanks,
--Kevin
________________________________________________________________________
________________________________________________________________________
Message: 2
Date: Tue, 18 May 2004 12:38:15 -0400
From: "Chad Everett" <[email protected]>
Subject: RE: Plugin versions for MT3
I haven't actually planned it out yet, but I'm thinking that for plugins
that care about the version, I'll 'freeze' existing plugins where they are,
and only issue new plugins (with new version numbers) for MT3. I'll
probably bump the version number to the next highest 'major' number to
indicate such a shift. Of course, if there's a bug or something it might
raise issues, but I'm pretty certain most of them are clean at the moment.
Dunno if this is a 'best practice', but like you I don't really want to
maintain separate versions. If the existing ones work, I'll leave them out
there. Then just move forward on the 'new' ones.
-----Original Message-----
From: Kevin Shay [mailto:[email protected]]
Sent: Tuesday, May 18, 2004 11:26 AM
To: [email protected]
Subject: [mt-dev] Plugin versions for MT3
Plugin developers,
If a given plugin needs to be updated (and/or can be enhanced) for
MT3, how are you planning to handle this? Do you intend to distribute
two separate versions of the plugin? Or put all the variant code in
one plugin and switch based on MT::VERSION?
I'd like to avoid maintaining two versions of 17 plugins, but I guess
putting all the code in one file would preclude the approach of
subclassing MT:
lugin in order to register it...Also, what about version numbering for your plugins?
Any thoughts on best practices would be appreciated.
[This message contained attachments]
________________________________________________________________________
________________________________________________________________________
Message: 3
Date: Tue, 18 May 2004 12:27:14 -0700
From: Ezra Cooper <[email protected]>
Subject: Re: Returning an Object from Callback?
Hi all,
Let me first explain the reasoning behind the way it works now, and
then we can talk a little bit about how it might better support what
you're trying to do.
If you're writing a plugin that creates an on-disk representation of
the object that's different from the in-memory representation--for
example, if you wanted to store it in some encoded form that was hidden
from the interface--then you have to ensure that the in-memory
representation never gets polluted with your transformations. That's
what the cloning step does for you: it gives you a database-level
object to mangle, while allowing the application to continue with an
application-level object.
Now, I understand the use case for what you're doing here: you actually
want your callback to modify the object, in both its in-memory and
on-disk forms. That sounds like a very useful case and one that we
should try to support.
So here's a proposal. What if the callback was given both the
"original" (app-level) object AND the "clone" (database-level) object.
According to your humour, then, you could modify one or both or
neither. The clone is the object that would get saved and the original
is the object that the application will continue to act upon in that
request.
Thoughts on this?
Ezra
On May 16, 2004, at 2:49 PM, Phil Ringnalda wrote:
> On 16 May 2004 20:39:54 -0000, jayseae wrote:
> > I added a log entry to the comments loop, and the value of visible
> is still
> > 1 after I've executed my pre-save callback that sets it to 0. I'm
> assuming
> > this is because the pre_save callback happens in a different scope,
> and while
> > that change is saved to the database, it's not maintained into the
> code in
> > Comments.pm. Even though it's saving 0, it's got a 1 there while
> the module
> > executes.
>
> D'oh. I had a reasonable answer, it just wasn't the right answer to
> the right question
>
> Take a look at the various save()s in lib/MT/ObjectDriver/ - they get
> the $obj, move $obj to $original, and put a clone of $obj in $obj,
> which then runs the callbacks. We don't get to touch the actual
> object, just the clone.
>
> Phil Ringnalda
>
>
[This message contained attachments]
________________________________________________________________________
________________________________________________________________________
Message: 4
Date: Tue, 18 May 2004 15:48:03 -0400
From: "Chad Everett" <[email protected]>
Subject: RE: Returning an Object from Callback?
Works for me.
-----Original Message-----
From: Ezra Cooper [mailto:[email protected]]
Sent: Tuesday, May 18, 2004 3:27 PM
To:
Subject: Re: [mt-dev] Returning an Object from Callback?
Hi all,
Let me first explain the reasoning behind the way it works now, and then we
can talk a little bit about how it might better support what you're trying
to do.
If you're writing a plugin that creates an on-disk representation of the
object that's different from the in-memory representation--for example, if
you wanted to store it in some encoded form that was hidden from the
interface--then you have to ensure that the in-memory representation never
gets polluted with your transformations. That's what the cloning step does
for you: it gives you a database-level object to mangle, while allowing the
application to continue with an application-level object.
Now, I understand the use case for what you're doing here: you actually want
your callback to modify the object, in both its in-memory and on-disk forms.
That sounds like a very useful case and one that we should try to support.
So here's a proposal. What if the callback was given both the "original"
(app-level) object AND the "clone" (database-level) object. According to
your humour, then, you could modify one or both or neither. The clone is the
object that would get saved and the original is the object that the
application will continue to act upon in that request.
Thoughts on this?
Ezra
[This message contained attachments]
________________________________________________________________________
________________________________________________________________________
Message: 5
Date: Tue, 18 May 2004 13:39:56 -0700
From: Phil Ringnalda <[email protected]>
Subject: Re: Returning an Object from Callback?
On Tue, 18 May 2004 12:27:14 -0700, Ezra Cooper <[email protected]> wrote:
> If you're writing a plugin that creates an on-disk representation of
> the object that's different from the in-memory representation--for
> example, if you wanted to store it in some encoded form that was hidden
> from the interface--then you have to ensure that the in-memory
> representation never gets polluted with your transformations. That's
> what the cloning step does for you: it gives you a database-level
> object to mangle, while allowing the application to continue with an
> application-level object.
Ah, the store-in-XHTML edit-in-Textile thing. I'm so uninterested in
learning a new markup language that I missed that completely. I
probably would have tried doing it the hard and leaky way by combining
a pre-save encoding and a post-save decoding,
> So here's a proposal. What if the callback was given both the
> "original" (app-level) object AND the "clone" (database-level) object.
> According to your humour, then, you could modify one or both or
> neither. The clone is the object that would get saved and the original
> is the object that the application will continue to act upon in that
> request.
That should actually be more useful for both cases, since the
alternate markups seem to always be leaking into other things, like
excerpts: if you know that remove_html won't clean you up for an
auto-generated excerpt, you can auto-generate your own and stick in in
the app's object for use in pinging. I like it!
Phil Ringnalda
________________________________________________________________________
________________________________________________________________________
Message: 6
Date: Wed, 19 May 2004 07:28:44 -0400
From: "Chad Everett" <[email protected]>
Subject: Implementing add_plugin_slug?
I've been trying to figure out how to get the add_plugin_slug function to
work, and have to say that I'm still stumped. I installed Tim's mt-rssfeed
to see how it worked, and couldn't seem to get that to display anything
either (though perhaps I don't have something enabled correctly).
Are there any working examples of how this is supposed to be specified?
Thanks!
---
Chad Everett
[email protected]
________________________________________________________________________
________________________________________________________________________
Message: 7
Date: Wed, 19 May 2004 14:41:20 -0000
From: "Timothy Appnel" <[email protected]>
Subject: Re: Implementing add_plugin_slug?
Somewhere along the alpha trail the add_plugin_slug method and the Plugin
API changed.
Sorry if I caused any confusion not releasing a version that worked with the
updated API.
In the "real" mt-feeds plugin I'm working on now, I'm doing this (put into
generic terms):
package MT::Foo;
use MT;
use vars qw($VERSION);
$VERSION = '1.0';
eval{ require MT:
lugin };unless ($@) {
my $about = {
name => "Foo $VERSION",
description => 'From foo with love.',
dir_name => "foo",
config_link => 'config.cgi'
};
MT->add_plugin( new MT:
lugin($about) );}
This seems to work nicely for registering the plugin if running under 3.0
(and presumably
up) while not creating errors for 2.661 users.
I read some of the earlier posts on versions and think it was right on. I
intend on going
over and updating all of my plugins. (They needed to be cleaned up any way.)
If I decide to
add 3.0 specific functionality I'll create a new major version and keep the
old version
available for MT2 users. (This is similar to what Apache did with their
process-based and
thread-based servers.) If a plugin doesn't take advantage of MT3 functions,
I'll just add the
above to optionally register it if I can.
Hope that helps.
<tim/>
________________________________________________________________________
________________________________________________________________________
Message: 8
Date: Wed, 19 May 2004 11:26:27 -0400
From: "Chad Everett" <[email protected]>
Subject: RE: Re: Implementing add_plugin_slug?
Did the trick. Thanks!
The dir_name doesn't seem to be documented either on the online tutorial or
in Plugin.pm. What does it do?
Is there any standard established for config_links? The plugins I've
developed that are executable on their own, I've always put into the MT
directory - but that doesn't have to be the case. Is there anything in mind
at this point?
-----Original Message-----
From: Timothy Appnel [mailto:[email protected]]
Sent: Wednesday, May 19, 2004 10:41 AM
To:
Subject: [mt-dev] Re: Implementing add_plugin_slug?
package MT::Foo;
use MT;
use vars qw($VERSION);
$VERSION = '1.0';
eval{ require MT:
lugin };unless ($@) {
my $about = {
name => "Foo $VERSION",
description => 'From foo with love.',
dir_name => "foo",
config_link => 'config.cgi'
};
MT->add_plugin( new MT:
lugin($about) );}
[This message contained attachments]
________________________________________________________________________
________________________________________________________________________
Message: 9
Date: Wed, 19 May 2004 15:38:51 -0000
From: "Timothy Appnel" <[email protected]>
Subject: Re: Implementing add_plugin_slug?
You'll have to forgive me because I've been at testing and disecting the
code for the past
couple of months that I've forgotten were I saw some of this.
Plugins can now have their own subdirectory in the /plugins directory. This
is because
plugins will surely begin to have multiple files with the expanded
capabilities of MT3's
plugin API. This keeps things neat and organized. So the dir_name defines to
MT what the
name of the plugins subdirectory any other related files (such as
config.cgi) are located.
That's roughly it. I suppose the best practice will be if your plugin has
more then one file
(not counting modules which should go in extlib or perhaps templates which
should go in
their own subdirectory of /tmpl) then you should include a dir_name
attribute. Otherwise
just place it in the main plugins directory with a descriptiive/unique name.
<tim/>
________________________________________________________________________
________________________________________________________________________
Message: 10
Date: Wed, 19 May 2004 11:42:49 -0400
From: "Chad Everett" <[email protected]>
Subject: SCRIPT_URL in header.tmpl
Header.tmpl holds a parameter named SCRIPT_URL, which has the script that
submitted the template. In most cases (if not all) within the UI, the value
of this parameter is 'mt.cgi'.
If I create a config_link for a plugin, let's say mt-myplugin.cgi, then when
I use header.tmpl in a template that script generates, the value of
SCRIPT_URL will be mt-myplugin.cgi. This means the links in header.tmpl
will be hosed.
Does anyone know of any way to get around this? Either by adding a method
to mt.cgi (MT::APP?) or faking out the build_page process so that it will
get mt.cgi instead of mt-myplugin.cgi?
I can hack build_page, but I'd rather not. I could build a duplicate of
build_page in my plugin (and have in the past), but that isn't as clean and
it needs to be updated whenever the 6A code gets updated. I could create my
own header template (or handle it in my plugin template), but again that
seems to duplicate effort.
Perhaps I could add in code to my plugin to handle all possible links that
might be in the UI and pass those off to the MT::APP functions? Again
kludgy, and if the parameters change or new features are added, I've got to
update the template again.
Any ideas?
---
Chad Everett
[email protected]
________________________________________________________________________
________________________________________________________________________
Message: 11
Date: Wed, 19 May 2004 17:17:28 -0000
From: "Timothy Appnel" <[email protected]>
Subject: Re: SCRIPT_URL in header.tmpl
The quick fix is to overload the uri method in MT::App. Instead of this:
sub uri { $_[0]->path . $_[0]->script }
Use this in your subclass:
sub uri { $_[0]->path . MT::ConfigMgr->instance->AdminScript }
This isn't perfect and its untested so you could still get tripped up. If
you make a call to uri
and expect your script's url this fix will cause issues. If mt.cgi is
running under https while
your script is under http is another that leapt to mind. (Really they should
run under the
same protocol. If not a little redirect magic could remedy that.) Its likely
I may overlooked
something else in my haste. If you win the developer's contest do I get a
percentage of the
prize?
What really needs to happen is that header and footer templates gets split
out. That
particular instance of SCRIPT_URL should be loaded up using the AdminScript
configuration param (or default) and a utility class created for loading up
the appropriate
data into the structure HTML::Template expects.
<tim/>
________________________________________________________________________
________________________________________________________________________
Message: 12
Date: Wed, 19 May 2004 13:30:42 -0400
From: "Chad Everett" <[email protected]>
Subject: RE: Re: SCRIPT_URL in header.tmpl
If I should happen to win something, I'm sure we can work something out.
-----Original Message-----
From: Timothy Appnel [mailto:[email protected]]
Sent: Wednesday, May 19, 2004 1:17 PM
To:
Subject: [mt-dev] Re: SCRIPT_URL in header.tmpl
If you win the developer's contest do I get a percentage of the prize?
________________________________________________________________________
________________________________________________________________________
Message: 13
Date: Wed, 19 May 2004 13:30:30 -0400
From: "Chad Everett" <[email protected]>
Subject: RE: Re: Implementing add_plugin_slug?
No forgiveness necessary, Tim.
The dir_name value doesn't seem to be used anywhere that I can find it. Is
this something that will be coming in the future? There is an 'envelope' in
Plugin.pm that looks like it is used in CMS.pm, which in turn seems as if it
may be doing the same thing you're talking about here, but I can't seem to
get it to work as I'd expect it to work. No worries for now - mostly just
curious.
Thanks again.
---
Chad Everett
[email protected]
________________________________________________________________________
________________________________________________________________________
Message: 14
Date: Wed, 19 May 2004 11:45:53 -0700
From: Ezra Cooper <[email protected]>
Subject: Re: Re: Implementing add_plugin_slug?
On May 19, 2004, at 10:30 AM, Chad Everett wrote:
> No forgiveness necessary, Tim.
>
> The dir_name value doesn't seem to be used anywhere that I can find
> it. Is
> this something that will be coming in the future? There is an
> 'envelope' in
> Plugin.pm that looks like it is used in CMS.pm, which in turn seems
> as if it
> may be doing the same thing you're talking about here, but I can't
> seem to
> get it to work as I'd expect it to work. No worries for now - mostly
> just
> curious.
Hi guys--
Thanks for the excellent explanation of the newer plugin slug
interface, Tim. To confirm that, I suggest creating a directory for
your plugin if it has more than one file.
The dir_name parameter for MT:
lugin is obsolete, actually. Werealized that we could set that value automatically when loading the
plugin so you don't have to specify it. This allows you to rename your
plugin directory (the "envelope") without changing the code. You can
query an MT:
lugin for its envelope by calling the envelope() method.Ezra
________________________________________________________________________
________________________________________________________________________
Message: 15
Date: Wed, 19 May 2004 13:23:40 -0700
From: Phil Ringnalda <[email protected]>
Subject: Re: Re: Implementing add_plugin_slug?
On Wed, 19 May 2004 11:45:53 -0700, Ezra Cooper <[email protected]> wrote:
>
> The dir_name parameter for MT:
lugin is obsolete, actually. We> realized that we could set that value automatically when loading the
> plugin so you don't have to specify it. This allows you to rename your
> plugin directory (the "envelope") without changing the code. You can
> query an MT:
lugin for its envelope by calling the envelope() method.>
Just to be sure I'm not still confused:
I have one file, I put it in /plugins/simpleplugin.pl
I have two files, I put them in /plugins/fancyplugin/fancyplugin.pl
and /plugins/fancyplugin/fancyconfig.cgi?
That's where I was missing the point of the envelope, thinking that I
would put fancyplugin.pl in /plugins/ and fancyconfig.cgi in
/plugins/fancyplugin/.
Phil Ringnalda
________________________________________________________________________
________________________________________________________________________
Message: 16
Date: Wed, 19 May 2004 23:44:01 -0000
From: "tsbalaban" <[email protected]>
Subject: Adding functions accessiblr by mt.cgi
I have an options.pm with functions of mine that call CMS functions.
I want to add my function references in my "add_methods" call of my
sub init to the function references in the CMS sub init. This way
all mine and CMS functions are accessible to mt.cgi by the __mode
parameter. Would it help to make my functions global and how?
Thanks for any help.
Ted
________________________________________________________________________
________________________________________________________________________
Message: 17
Date: Wed, 19 May 2004 23:49:50 -0000
From: "tsbalaban" <[email protected]>
Subject: Adding functions accessible by mt.cgi
I have an options.pm with functions of mine that call CMS functions.
I want to add my function references in my "add_methods" call of my
sub init to the function references in the CMS sub init. This way
all mine and CMS functions are accessible to mt.cgi by the __mode
parameter. Would it help to make my functions global and how?
Thanks for any help.
Ted
