nexpay

پلاگين براي ام تي 3

شروع موضوع توسط Azemati ‏26 می 2004 در انجمن MovableType - مووبل تایپ

  1. Azemati

    Azemati کاربر فعال مووبل تایپ<br> فروشنده معتبر [<a title= کاربر فعال

    تاریخ عضویت:
    ‏18 فوریه 2003
    نوشته ها:
    3,366
    تشکر شده:
    1
    محل سکونت:
    wp-config.php
    متن نامه هاي يك سري از پلاگين كار هاي ام تي كه در مورد پلاگين هاي ورژن 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::plugin 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::plugin 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::plugin };
    unless ([email protected]) {
    my $about = {
    name => "Foo $VERSION",
    description => 'From foo with love.',
    dir_name => "foo",
    config_link => 'config.cgi'
    };
    MT->add_plugin( new MT::plugin($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::plugin };
    unless ([email protected]) {
    my $about = {
    name => "Foo $VERSION",
    description => 'From foo with love.',
    dir_name => "foo",
    config_link => 'config.cgi'
    };
    MT->add_plugin( new MT::plugin($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::plugin 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::plugin 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::plugin 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::plugin 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​
     
  2. Azemati

    Azemati کاربر فعال مووبل تایپ<br> فروشنده معتبر [<a title= کاربر فعال

    تاریخ عضویت:
    ‏18 فوریه 2003
    نوشته ها:
    3,366
    تشکر شده:
    1
    محل سکونت:
    wp-config.php
  3. babakweb

    babakweb Registered User

    تاریخ عضویت:
    ‏29 اکتبر 2003
    نوشته ها:
    1,757
    تشکر شده:
    36
    محل سکونت:
    Tehran
    چه جوري اينها رو پيدا كردي؟
     
  4. Azemati

    Azemati کاربر فعال مووبل تایپ<br> فروشنده معتبر [<a title= کاربر فعال

    تاریخ عضویت:
    ‏18 فوریه 2003
    نوشته ها:
    3,366
    تشکر شده:
    1
    محل سکونت:
    wp-config.php
  5. ehsan

    ehsan Administrator

    تاریخ عضویت:
    ‏5 دسامبر 2002
    نوشته ها:
    7,915
    تشکر شده:
    3,503
    محل سکونت:
    Internet
    منظورت چیه؟

    راستی یکی دو تاش رو خوندم. جالب بود. میدونید که 20000 دلار جایزه گذاشتن برای پلاگین ها!
     
  6. Azemati

    Azemati کاربر فعال مووبل تایپ<br> فروشنده معتبر [<a title= کاربر فعال

    تاریخ عضویت:
    ‏18 فوریه 2003
    نوشته ها:
    3,366
    تشکر شده:
    1
    محل سکونت:
    wp-config.php
    اگه متن انگليسي رو ببيني ، متوجه مي شي كه rtl هست. در صورتي كه بايد ltr باشه تا نقطه ها و علامت سوال و اينها درست نشون داده بشن. درسته؟
    من جايي توي اديتور پيدا نكردم كه اينو ltr كنم.
     
  7. babakweb

    babakweb Registered User

    تاریخ عضویت:
    ‏29 اکتبر 2003
    نوشته ها:
    1,757
    تشکر شده:
    36
    محل سکونت:
    Tehran
    همين طوري مي خواستم بدونم!
     
  8. Azemati

    Azemati کاربر فعال مووبل تایپ<br> فروشنده معتبر [<a title= کاربر فعال

    تاریخ عضویت:
    ‏18 فوریه 2003
    نوشته ها:
    3,366
    تشکر شده:
    1
    محل سکونت:
    wp-config.php
    توي يكي از گروه هاي ياهو عضوم كه در مورد ام تي هست و اكثر اين پلاگين نويسها و اينها هم عضون. از اونجا نامه ها رو آوردم.
     
  9. babakweb

    babakweb Registered User

    تاریخ عضویت:
    ‏29 اکتبر 2003
    نوشته ها:
    1,757
    تشکر شده:
    36
    محل سکونت:
    Tehran
    آهان!
    بابك
     
  10. ehsan

    ehsan Administrator

    تاریخ عضویت:
    ‏5 دسامبر 2002
    نوشته ها:
    7,915
    تشکر شده:
    3,503
    محل سکونت:
    Internet
    درست میگی. البته میتونستی از تگ کد استفاده کنی برای ltr شدن.
     
zarpopخرید بک لینک عسل طبیعی و گرده گل ایرانیfootbal