Are you using FCK to look at other pages in your Templates
NS? ...doesn't it cause the same problem? If not, there must be a
reason for it. It wasn't obvious for me at first; had to go looking
for trouble...
CW
On Sep 10, 8:54 am, "Yaron Koren" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> That's too bad. As you could guess, I have almost no knowledge of how
> FCKeditor works internally, let alone the ability to fix it... I'm
> guessing that the only time I'd get involved in trying to fix things
> is if FCK works differently in the form from how it works in the
> 'edit' page.
>
> -Yaron
>
>
>
> On Wed, Sep 10, 2008 at 6:43 AM, CW <[EMAIL PROTECTED]> wrote:
>
> > Yaron,
> > This is promising. I have a question about using FCKeditor, though,
> > because just yesterday I gave it a failing grade on our development
> > server where we test all extensions before applying them to our
> > production site. I found that it strips out some HTML tags when using
> > IE7 (I have a bug in, but that crowd doesn't seem to be as responsive
> > as the SMW/SF crowd--holding out little hope). Anyway, this problem
> > is evident primarily in templates with <pre> tags that show how to
> > call up a template on the template page view. ...I noticed it also
> > with comments in complex templates, for example I've copied the
> > Extension pages for all of the extensions we're running on our site
> > and I've moved them to the Help namespace and associated them with the
> > Advanced Editing or Administrators areas. ...and as you are probably
> > aware, there are a lot of <!---Comment---> tags inside the Infobox
> > Extension template. ...anyway, FCK was stripping them out, along with
> > everything inside them, so I was losing half my templates.
>
> > Realize this isn't the FCKeditor list....but if you know of a way to
> > fix this, maybe we could deploy it on Monday's release of our upgraded
> > wiki...
>
> > CW
>
> > On Sep 9, 3:16 pm, "Yaron Koren" <[EMAIL PROTECTED]> wrote:
> >> Hi everyone,
>
> >> Version 1.3 of Semantic Forms has been released. This is a major
> >> version release, with three new files, plus a lot of other additions
> >> and changes:
>
> >> - support was added (finally!) for WYSIWYG editing, using the
> >> FCKeditor MediaWiki extension. Currently it works only for the "free
> >> text" input, though eventually I hope that it will be able to edit
> >> other textarea inputs in the form. To get this working, you only need
> >> to install the FCKeditor extension on the wiki. If it shows up
> >> correctly in regular 'edit' pages, then it should also show up
> >> automatically in forms. Thanks a lot to Eugene Mednikov for this
> >> exciting new feature.
>
> >> - tied in with this new feature, I did some refactoring of the code,
> >> moving a lot of the Javascript and utility functions defined in
> >> /includes/SF_FormPrinter.inc into a new file,
> >> /includes/SF_FormUtils.inc. This should hopefully make the code
> >> somewhat more readable and manageable.
>
> >> - in a change that I probably should have done a while ago, the
> >> parsing of template calls has (I believe) been fixed, so that pages
> >> that contain templates calls within template calls, or variables like
> >> "{{PAGENAME}}" within template calls, are now handled correctly by
> >> forms. I should note that I have some mixed feelings about this bug
> >> fix: I don't personally think that inner templates and variables
> >> should be used, because it means that users will see curly braces
> >> within forms, which I think adds a lot of unnecessary confusion. But
> >> in any case, it works now.
>
> >> - new implementations for the #arraymap and #arraymaptemplate parser
> >> functions were added that handle embedded templates, variables and
> >> parser functions better, that work for versions of MediaWiki I believe
> >> 1.12 or higher; thanks very much to Daniel Friesen.
>
> >> - on pages that redirect the user, a "loading" image, which is one of
> >> those rotating circles, now appears on the page. This happens in two
> >> places: when the user enters a page name in the form input and is
> >> redirected to either 'AddData' or 'EditData', and when the user hits
> >> Save/Preview/etc. in a form and is redirected to the page itself, with
> >> its new content. The idea is that this image (a) let the user know
> >> what's going on, especially if the redirect takes a while, and (b)
> >> hopefully clarifies to users why they need to hit the "back" button
> >> twice to get back to the form. Thanks again to Eugene Mednikov for the
> >> idea and most of the code. We both agreed that this feature might get
> >> annoying, but that it's worth trying out to see what people think. So,
> >> let me know what you think. :)
>
> >> - per good MediaWiki practice, the ability to edit "restricted" form
> >> fields is no longer determined by who is allowed to delete pages, but
> >> rather set by a new permission type, 'editrestrictedfields'. By
> >> default this permission is assigned only to sysops in SF_Settings.php.
>
> >> - the 'AddPage' special page can now be used to redirect directly to
> >> forms - if one goes to a URL that looks like
> >> /Special:AddPage/form-name/page-name, it will redirect to either
> >> /Special:AddData/form-name/page-name or
> >> /Special:EditData/form-name/page-name, depending on whether or not the
> >> page exists. This is useful for linking to the editing of a page from
> >> outside the wiki.
>
> >> - the "listbox" form input type now takes a "size=" parameter.
>
> >> - the 'namespace=' parameter in the query string now works for forms
> >> that set an automatic page name - due to a bug, this wasn't working
> >> before.
>
> >> - I fixed a bug I added in the last version, 1.2.10, that added some
> >> whitespace to the top of very form.
>
> >> - another new file was added, '/includes/SF_FormEditPage.php', that
> >> holds a class that may eventually be used to let the form remain
> >> displayed when the user hits "Show preview" or "Show changes".
> >> Currently it's not yet in use, possibly pending some more changes to
> >> core MediaWiki code, but hopefully it will be usable by the time
> >> MediaWiki 1.14 is released. Thanks again to Daniel Friesen for his
> >> dedicated work on this feature.
>
> >> - MediaWiki has a new feature that lets you create aliases for special
> >> pages, so that a certain special page can be reached at more than one
> >> name. SF now has support for this feature, in a new file called
> >> /languages/SF_Aliases.php - thanks to internationalization guru
> >> Siebrand Mazeland for this addition.
>
> >> - language support was added for Erzya and Gothic.
>
> >> By the way, if you're wondering, I'm not trying to sync up SF's
> >> version numbers with those of Semantic MediaWiki, although it
> >> certainly looks that way... SF's release schedule so far has been
> >> faster than SMW's, so they'll probably be out of sync again before
> >> long.
>
> >> -Yaron- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Semantic Forms" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/semantic-forms?hl=en
-~----------~----~----~----~------~----~------~--~---
