search dialog: Clone this page

[Jürgen Weber]

Hi,

if you click the magnifier to search, there appears a [] Clone this page option.
Can you prevent the option from appearing?
If you check the option, the current page is cloned, I am not quite
certain why this is in the search dialog, anyway.

Greetings,
Juergen

Re: template / skin still work

[Jürgen Weber]

Hi Dirk,

thanks for the pointer.

So, we cannot use the classic skin anymore? To go to the Css Themes
would mean some porting work.

I had found

https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11

> Haddock as new default template
> if you need to revert to the 2.10 default template, you should set the 
> jspwiki.templateDir property to 210 on your jspwiki[-custom].properties file

So I tried it.

Greetings,
Juergen

Am Mi., 6. Apr. 2022 um 23:22 Uhr schrieb Dirk Frederickx
:
>
> Hi Juergen,
>
> The default jspwiki template is now based on the Haddock Template.
> It doesn't support skins. Instead it introduces the notion of Themes via
> the use of %%add-css.
>
> Please check https://jspwiki-wiki.apache.org/Wiki.jsp?page=Category.Themes
>
> KR
> dirk
>
>
> On Wed, Apr 6, 2022 at 4:50 PM Jürgen Weber  wrote:
>
> > Hi,
> >
> > I am porting our JSPWiki instances to new machines and current.
> > Should the template / skin machanism still work?
> >
> > I tried setting
> >
> > jspwiki.templateDir = 210
> >
> > jspwiki.defaultprefs.template.skinname = Ours
> >
> > but it seems it does not trigger. Also I found no use of
> > jspwiki.templateDir in the code of jspwiki-main
> >
> > Greetings,
> > Juergen
> >

template / skin still work

[Jürgen Weber]

Hi,

I am porting our JSPWiki instances to new machines and current.
Should the template / skin machanism still work?

I tried setting

jspwiki.templateDir = 210

jspwiki.defaultprefs.template.skinname = Ours

but it seems it does not trigger. Also I found no use of
jspwiki.templateDir in the code of jspwiki-main

Greetings,
Juergen

Security Manager Removal

[Jürgen Weber]

There is a JEP to deprecate the Security Manager.

Is that relevant for JSPWiki? There is the jspwiki.policy, does
anybody know, if that needs the security manager?

JEP 411: Deprecate the Security Manager for Removal
https://openjdk.java.net/jeps/411

Re: logger changes for 2.11.0

[Jürgen Weber]

oon as
> > > possible, as the old methods should disappear on a-not-yet-defined
> > > moment in the future). The jspwiki-210-adapters artifact should
> > > reroute old methods to new ones. The jspwiki-210-test-adaptees tests
> > > that the former module behaves as expected so, if it doesn't, then
> > > that should be a bug :-/
> > >
> > > The rationale of the change began on JSPWIKI-303 (to provide an API
> > > library); unfortunately this was easier said than done, as the
> > > signature of the methods included the WikiContext, which is tied to
> > > the WikiEngine, which in turn is tied to almost all JSPWiki code.
> > > Thus, all the interfaces extraction for the api module, and the
> > > changes on the WikiEngine et all between 2.10 and 2.11.
> > >
> > >
> > > HTH,
> > > juan pablo
> > >
> > > On Fri, Dec 17, 2021 at 8:39 PM Jürgen Weber  wrote:
> > >>
> > >> Finally found some time to update to 2.11.0.
> > >> Experience was mixed.
> > >> Had to port my plugins to the changed API (kind of frivolous to change
> > >> the API of a mature product, I dare to say, and break all existing
> > >> plugins), but this went rather smoothly.
> > >> But I didn't get the new logging to work. Do I really have to add some
> > >> 50 lines to my jspwiki-custom.properties to get a simple file logging?
> > >> Aren't there defaults?
> > >> Has anybody some simple lines to get a file log?
> > >>
> > >> Thanks,
> > >> Juergen
> >
> >

logger changes for 2.11.0

[Jürgen Weber]

Finally found some time to update to 2.11.0.
Experience was mixed.
Had to port my plugins to the changed API (kind of frivolous to change
the API of a mature product, I dare to say, and break all existing
plugins), but this went rather smoothly.
But I didn't get the new logging to work. Do I really have to add some
50 lines to my jspwiki-custom.properties to get a simple file logging?
Aren't there defaults?
Has anybody some simple lines to get a file log?

Thanks,
Juergen

Re: Converting JSPWiki to HTML

[Jürgen Weber]

There is

https://jspwiki.apache.org/apidocs/2.11.0.M4/org/apache/wiki/WikiEngine.html#getHTML-java.lang.String-

Guess you could add a servlet/service/tag to JSPWiki that calls it

Am Di., 5. Okt. 2021 um 12:27 Uhr schrieb Archan Ranade
:
>
> Hi,
>
> Please let me know how to convert JSPWiki to HTML as a standalone utility? I 
> do not want to deploy the JSPWiki to a Tomcat server. Instead, I want to 
> achieve the functionality of converting JSPWiki to HTML through a main 
> program as a standalone utility. Please let me know how to do this. The other 
> way around seems simple enough by using HtmlStringToWikiTranslator for HTML 
> to JSPWiki conversion. Please let me know how to do JSPWiki to HTML.
>
>
> Thanks,
> Archan Ranade
>
> [Logo]
>
> Archan Ranade | Software Engineer
>
> e: archan.ran...@opshub.com  | w: 
> https://www.opshub.com/
> p:  +1.650.701.1800
>
> [facebook icon] [twitter icon] 
>   [youtube icon] 
>  
>  [linkedin icon] 
>
>

Re: JSPWiki installation problem on WebLogic 12.2.1.4.0

[Jürgen Weber]

I did a quick check with WLS 14.1.1 and current JSPWiki.
Deploying the war gave an error, deploying from the war exploded in a
folder worked. I used a jspwiki-custom.properties that points to pages
etc in the WLS pre classpath.

Juergen

Am Fr., 5. Feb. 2021 um 03:55 Uhr schrieb Wu Jason :
>
> Hi,
>
> I was trying to install the JSPWiki 2.11.0.M8 on WebLogic version 12.2.1.4.0.
> The installation was not successful due to the following error:
>
> ERROR org.apache.wiki.api.core.Engine  - failed to load security policy from 
> file jspwiki.policy
>
> But I have checked the jspwiki.policy is inside the WEB-INF folder. And the 
> war file can be installed on Tomcat 9 properly.
>
> I found a similar closed issue on the issue tracker, not sure if it is 
> related or not:
> https://issues.apache.org/jira/browse/JSPWIKI-1029
>
> Any idea why the JSPWiki cannot see the jspwiki.policy on WebLogic? Thank a 
> lot.
>
> Part of the stacktrace of the error below:
> ERROR org.apache.wiki.api.core.Engine - failed to load security policy from 
> file jspwiki.policy,stacktrace follows
> java.io.FileNotFoundException: jspwiki.policy not found
> at org.apache.wiki.api.core.Engine.findConfigFile(Engine.java:274)
> at 
> org.apache.wiki.auth.DefaultAuthorizationManager.initialize(DefaultAuthorizationManager.java:244)
> at org.apache.wiki.WikiEngine.initComponent(WikiEngine.java:405)
> at org.apache.wiki.WikiEngine.initComponent(WikiEngine.java:393)
> at org.apache.wiki.WikiEngine.initialize(WikiEngine.java:320)
> at org.apache.wiki.WikiEngine.(WikiEngine.java:225)
> at org.apache.wiki.WikiEngine.getInstance(WikiEngine.java:183)
> at org.apache.wiki.spi.EngineSPIDefaultImpl.find(EngineSPIDefaultImpl.java:41)
>
> Regards,
> Jason Wu

Re: How to configure JspWiki on Wildfly?

[Jürgen Weber]

a) create a wildfly resource module:
https://developer.jboss.org/thread/219956?_sscc=t
and make it global:
https://docs.jboss.org/author/display/WFLY10/Subsystem+configuration?_sscc=t

b) or use the -Djspwiki.custom.config=/java/JSPWiki/jspwiki-custom.properties"

Am Mo., 11. Feb. 2019 um 23:24 Uhr schrieb Peter Nabbefeld
:
>
>
> Hello,
>
> I've installed JspWiki on JBoss Wildfly, but I cannot figure out where
> to put the configuration file.
>
> Wildfly is running in standalone mode as its own user, so JspWiki is
> deployed in
> /opt/wildfly/standalone/tmp/vfs/deployment/deploymentxxx/jspwiki-main-2.11.0.M1.jar-yyy
>
> Temporary files are deleted on disable, so it seems a bad idea to put
> any configuration files there. I've tried to put
> jspwiki-custom.properties into /opt/wildfly/appclient/configuration/,
> but it seems not to be used, as well as the one created by Install.jsp
> script (checked after restart using "ll -u").
>
> BTW, wiki files are properly stored under /opt/wildfly/jspwiki-files.
>
> The only possible options I'm currently aware of:
>
> 1. Setting java.io.tmpdir - why is /tmp used for a properties file?
> IMHO, mixing configuration with temporary data isn't a good idea, but
> probably I'm just missing sth.
>
> 2. Adding a deployment overlay
> (https://docs.jboss.org/author/display/WFLY8/Deployment+Overlays). While
> this seems at least a bit better, I'll have to "replace" the whole
> jspwiki.properties file, which may lead to problems when jspwiki evolves
> and yet not existing options will be removed because thy're missing in
> the overlay file.
>
> Is there any option I can set to just change the path to
> jspwiki-custom.properties?
>
> Kind regards
>
> Peter
>

Re: Can jspwiki be used for large deployment

[Jürgen Weber]

guess not, on startup JSPWiki loads all pages into memory to parse
intra-page links.

2018-03-22 5:24 GMT+01:00 dagarwa...@gmail.com :
> JspWiki uses filesystem instead of a conventional database. Would you suggest 
> using jspwiki if it were to cater to 1billion page ? (Provided, a solid 
> backup mechanism ). Would it scale that much with both performance and 
> data-integrity perspective ?

Re: Data Migration

[Jürgen Weber]

Forgive my  ignorance. The old JDBCProvider has been ported and linked
by https://jspwiki-wiki.apache.org/Wiki.jsp?page=ContributedProviders

Jürgen

Re: Data Migration

[Jürgen Weber]

Col, will you port the old JDBCProvider?

Am 28.11.2017 16:56 schrieb "Col Willis" <col.wil...@gmail.com>:

> I will look at that migratePlugin - Thanks.
>
> I thought of developing a Page Crawler using XML RPC; to re-create on the
> New Wiki.
>
> Is it possible to Download attachments/Files via the XMLRPC?
>
>
>
> On 28 November 2017 at 15:45, Jürgen Weber <juer...@jwi.de> wrote:
>
> > Well, there once was a JDBCProvider, might be fun to port it to current
> > JSPWiki ..
> >
> > License is LGPL.
> >
> > https://www.ecyrd.com/JSPWiki/wiki/JDBCProviders
> >
> > As for migrating, I once hacked a simple Plugin to migrate to a different
> > provider, it might be useful as copy template..
> >
> > https://github.com/weberjn/migratePlugin
> >
> > Jürgen
> >
> > Am 28.11.2017 14:16 schrieb "Col Willis" <col.wil...@gmail.com>:
> >
> > > Hi all,
> > >
> > > I have a personal JSPWiki for a few years with File-based storage
> > > (jspwiki-files)
> > >
> > > I want to migrate this to AWS Cloud, but setup a Database back-end...
> > >
> > > What is the best way to Migrate data from jspwiki-files into Database?
> > >
> > >
> > > Thanks,
> > >
> > > Colin
> > >
> >
>
>
>
> --
> Col
>

Re: Data Migration

[Jürgen Weber]

Well, there once was a JDBCProvider, might be fun to port it to current
JSPWiki ..

License is LGPL.

https://www.ecyrd.com/JSPWiki/wiki/JDBCProviders

As for migrating, I once hacked a simple Plugin to migrate to a different
provider, it might be useful as copy template..

https://github.com/weberjn/migratePlugin

Jürgen

Am 28.11.2017 14:16 schrieb "Col Willis" :

> Hi all,
>
> I have a personal JSPWiki for a few years with File-based storage
> (jspwiki-files)
>
> I want to migrate this to AWS Cloud, but setup a Database back-end...
>
> What is the best way to Migrate data from jspwiki-files into Database?
>
>
> Thanks,
>
> Colin
>

JSPWiki mobile experience

[Jürgen Weber]

Hi,

anybody out there with good CSS skills, who could give JSPWiki a good
mobile experience?

I guess LeftMenue would have to go into a drop down menue.

https://issues.apache.org/jira/browse/JSPWIKI-835

Juergen

Re: Configuring a public JSPWiki instance for private use

[Jürgen Weber]

Wouldn't a good tutorial be enough?

Basically you just have to add a user to tomcat-users.xml, enable container
managed security in web.xml and edit the policy (maybe we should include
the default policy, that is more restricted and just works).

Wordpress and friends have zillions of security holes, whereas we can rely
mostly on proven container security.

Juergen

Am 06.10.2017 01:35 schrieb "David Vittor" <dvit...@gmail.com>:

> I kind of feel both sides of the argument are right here. Even though
> JSPWiki has a pretty great authentication system, the problem is it's not
> very user friendly.
>
> The solution I think is to build some sort of an "admin" UI into JSP wiki
> which lets users configure group/user permissions, and then saves these
> into the back end jspwiki.policy file.
>
> I think that is one thing that Confluence did really well, even though the
> backend is complex the front end is easy to manage. I think JSPWiki needs
> to the same. There is actually in the code a "hidden" admin page, but it's
> very buggy, and not sure how much additional work is needed to make this
> public.
>
> The other solution might be to use the tomcat group/user configurations
> with JAAS, but this probably needs better documentation, that is easy to
> follow.
>
> Every person/organisation has different requirements for how they want
> security to work. But that should not stop us making every effort to make
> it more user friendly.
>
> Anyway they are my thoughts.
>
> Cheers,
> David V
>
>
>
>
> On Fri, Oct 6, 2017 at 10:01 AM, Paul Uszak <paul.us...@gmail.com> wrote:
>
> > "What is JSPWiki for?" This then is the question.  If we kneel before our
> > god(s), hands on heart, lovingly think of our grandmothers and ask
> > ourselves “Can JSPWiki effectively compete in the content management
> > market” , what's the honest answer?  I think deep down in our souls it's
> an
> > emphatic “no”.
> >
> > I created a test Wordpress account last night in under five minutes. It
> > looks great and you get free hosting.  Wix offers even more fantastical
> > creativity when you enrol.  And xml editing wasn't needed.  Foswiki is
> more
> > powerful and polished, and used extensively.  Pretty tough competition.
> >
> > But the market isn’t crowded at the bottom.  It’s empty.  This isn’t a
> daft
> > strategy.  It’s the quintessential definition of strategic marketing.  An
> > analogous example is the tool Vi.  Vi is still cherished and extensively
> > used, even today configuring state of the art IaaS deployments. Simple
> can
> > be successful.  I can see a need (which is where I came on board) for a
> > plain and simple Wiki.  I use mine as a single user web site where it
> acts
> > as a content management system.
> >
> > Low system requirements, low bandwidth and most importantly, low
> > configuration.  Zero configuration to start.  The details can be thrashed
> > out later, but JSPWiki’s offering and place in the market must be
> resolved
> > for success.  I’ve posed this question before, but I’m not sure that
> > there’s sufficient appetite for answering it sincerely.  C'est la vie.
> >
> >
> > On 5 October 2017 at 21:49, Jürgen Weber <juer...@jwi.de> wrote:
> >
> > > Jim,
> > >
> > > I also think the JSPWiki Authorization system is very good. The
> > > container looks after authentication, and the policies decide what the
> > > Container authenticated user is allowed too.
> > >
> > > Kudos to Andrew Jaquith (https://www.ecyrd.com/
> > JSPWiki/wiki/AndrewJaquith)
> > >
> > > Juergen
> > >
> > > https://jspwiki-wiki.apache.org/Wiki.jsp?page=
> > > JSPWikiContainerManagedAuthenticationInstallation
> > >
> > > 2017-10-05 10:39 GMT+02:00 Jim Willeke <j...@willeke.com>:
> > > > Try not to think of it as infinite complexities but rather infinite
> > > > Combinations. ;)
> > > >
> > > > And if you have a suggestion or a request for an improvement, I am
> sure
> > > > folks would listen.
> > > >
> > > > I do agree many of the JSPWiki pages could use some refactoring.
> > > > As with MOST open source projects the docs and code they are out of
> the
> > > > beyond the realm of understanding for "common folk".
> > > >
> > > > Oh, and on "And how can you even dream of having anonymous users on
> an
> > > > internet facing
> > > > wiki?"
> > > > Many are, even Wi

Re: Configuring a public JSPWiki instance for private use

[Jürgen Weber]

oups and Page ACLs were deliberately meant to be managed outside
>> of
>> > the web container or java.policy so that users can create discretionary
>> > "roles" without getting system admins involved. This is an intentional
>> > feature, and a very powerful one which along with Page ACLs reduces the
>> > barrier to adoption.
>> > We all know the difficulty of getting some administrator in some other
>> area
>> > of an organization to grant (or deny) access to a "thing".
>> >
>> > Note that the hierarchy for Access Control is: (I do not see this
>> > documented, it was in a user group a few years back)
>> >
>> >- "built-in" roles
>> >- container-managed roles
>> >- WIKI-Groups
>> >- WIKI-Profiles
>> >
>> > AFIK, any "Container" implementation deals with deal with file
>> permissions,
>> > "Container" permissions.
>> >
>> > There are some complexities that may documented but not so well for those
>> > not familiar with the concepts.
>> > I think this page probably summarise most of the concepts:
>> > https://jspwiki-wiki.apache.org/Wiki.jsp?page=Wiki.Admin.Security
>> >
>> > Questions, Comments and Suggestions for improvements are always welcome.
>> >
>> > --
>> > -jim
>> > Jim Willeke
>> >
>> > On Tue, Oct 3, 2017 at 10:06 PM, Paul Uszak <paul.us...@gmail.com>
>> wrote:
>> >
>> > > Well I still have trouble with the permissions /users after a  couple
>> of
>> > > years. All sorts of weird things happen.
>> > >
>> > > I've  stated previously that I consider the security configuration
>> > > extremely complicated, bordering on unusable.  You cannot have a
>> credible
>> > > product that uses (simultaneously) file permissions, web container
>> > > permissions, wiki policies and per page directives.  I can't think of
>> > > another application that has such complex security across so many
>> levels.
>> > > It's madness - do you hear me?  Sheer madness :-)
>> > >
>> > > Seriously, I would suggest a  total overhaul to simplify massively. I'd
>> > > even consider writing some clearer documentation.   It might reduce the
>> > > number of set up issues that appear here. Although, with four
>> dimensional
>> > > security I suspect I'm not up to it.
>> > >
>> > > What was the question again..?
>> > >
>> > > It seems to me that if only the front page is publicly visible, it
>> > needn't
>> > > be within the wiki's context.  Simply have a static front page at one
>> > URI,
>> > > and have the private wiki at another.  It also means you don't have to
>> > > explain why you're being unfriendly as the wiki will be invisible
>> > > (unlinked).  I have something similar myself.  Or have I misunderstood?
>> > >
>> > > On 3 October 2017 at 20:09, Jürgen Weber <juer...@jwi.de> wrote:
>> > >
>> > > > Hi,
>> > > >
>> > > > I followed Dave's blog entry at
>> > > >
>> > > > https://blog.davekoelmeyer.co.nz/2014/07/20/configuring-a-
>> > > > public-jspwiki-instance-for-private-use/
>> > > >
>> > > > Has someone tried to keep the front page public? (i.e. to give a
>> > > > friendly reason for the rest of the pages being private)
>> > > >
>> > > > I tried to give all front facing pages [{ALLOW view ALL}]
>> > > > but still only the login prompt.
>> > > >
>> > > > Greetings,
>> > > > Juergen
>> > > >
>> > >
>> >
>>

Re: Configuring a public JSPWiki instance for private use

[Jürgen Weber]

Peter,

that is exactly what I was looking for.

Thanks very much,
Juergen


2017-10-04 9:59 GMT+02:00 Peter Hormanns :
>> put the ACLs into jspwiki.policy :
>>
>> Something like
>>
>> grant principal com.ecyrd.jspwiki.auth.authorize.Role "All" {
>> permission com.ecyrd.jspwiki.auth.permissions.PagePermission
>> "*:LeftMenu", "view";
>> permission com.ecyrd.jspwiki.auth.permissions.PagePermission
>> "*:LeftMenuFooter", "view";
>> permission com.ecyrd.jspwiki.auth.permissions.PagePermission
>> "*:Main", "view";
>> permission com.ecyrd.jspwiki.auth.permissions.PagePermission
>> "*:Impress", "view";
>> permission com.ecyrd.jspwiki.auth.permissions.PagePermission
>> "*:Forbidden", "view";
>> permission com.ecyrd.jspwiki.auth.permissions.WikiPermission "*",
>> "login";
>> };
>>
>
> replace "com.ecyrd.jspwiki.auth" by "org.apache.wiki.auth".
> I copied from an old configuration file.
>
>
> Peter
>
> --
> Peter Hormanns - Informatikbüro Hormanns & Wenz
> http://www.hormanns-wenz.de - Tel 02151 3274911
> Peter Hormanns - Hafenstraße 17 - 47809 Krefeld

Re: JSPWiki Feature Request

[Jürgen Weber]

> This would allow conversion of the wiki contents into a beautiful PDF without 
> much effort.

Have you tried opening a JSPWiki Page in Chrome and printing to PDF? I
do like the result.

Juergen

2017-02-21 12:07 GMT+01:00 Juan Pablo Santos Rodríguez
:
> Hi Dave,
>
> thanks for using JSPWiki! The preferred way to reach out for these things
> is through the user's ML (cc'ed), though, as it will reach more people and
> it's more likely you'll get an answer sooner.
>
> As for the global variables, you could check WikiVariables [#1] to see if
> that fits you. It's not exactly like MediaWiki's Magic Words, but I think
> it is close enough to what you want. Regarding using another markup parser,
> it should be possible as for [#2], but currently we're only having
> JSPWikiMarkupParser out of the box.
>
>
> HTH,
> juan pablo
>
>
> [#1]: https://jspwiki-wiki.apache.org/Wiki.jsp?page=WikiVariable
> [#2]: https://issues.apache.org/jira/browse/JSPWIKI-570
>
> On Mon, Feb 20, 2017 at 6:16 PM, Dave Jarvis  wrote:
>
>> Hi Juan,
>>
>> One more feature request: a pluggable Markdown/Wiki syntax that is
>> compatible with pandoc. This would allow conversion of the wiki contents
>> into a beautiful PDF without much effort.
>>
>> http://pandoc.org/try/
>>
>> Dave
>>
>>
>>

Re: Migrate JSPWiki contents from mysql to flat files

[Jürgen Weber]

I once hacked a Plugin to migrate between Providers:

https://github.com/weberjn/migratePlugin

It works by copying each page from one provider to another.

This is hardwired for my GitFileProvider, but it should be easy to
change for another provider.

Also you should add code for attachments.

Use at your own risk.

Cheers,
Juergen


2017-01-30 9:15 GMT+01:00 Fröhler Christian (Ext. - UniCredit Business
Integrated Solutions) :
> Hello,
>
> we have a JSPWiki installation; the contents are held within a Mysql database
> (jspwiki.pageProvider = com.forthgo.jspwiki.jdbcprovider.JDBCPageProvider)
>
> Now we move to another server, and there we want to store the contents in 
> flat files.
>
> Could you please advise how we can migrate the contents from Mysql DB to Flat 
> files; including attachments?
>
> Sorry if this has been asked before - couldn't find it in the mailing list 
> archives.
> (actually the question had been asked by someone on may 2013 but it seems 
> there was no response)
>
> thanks
> Christian
>
>

Re: OT (sort of): Nuxeo migrates off Confluence

[Jürgen Weber]

Thanks for the link.

Is there a Git-driven drive to source code based content?

Cheers,
Jürgen

2016-11-21 20:43 GMT+01:00 Dave Koelmeyer :
> Nuxeo is a major open source enterprise documentation management system
> product. Their developer team recently migrated all documentation from
> Confluence to a static site generator. While not related directly to
> JSPWiki, the reasons why they switched are interesting, and it's not
> every day one hears about a switch from the Microsoft Office of wikis:
>
> https://www.nuxeo.com/blog/from-confluence-to-metalsmith-a-migration-story-of-nuxeo-docs/
>
> This could provide some insight into potential features for JSPWiki down
> the line.
>
> Cheers,
> Dave
>
> --
> Dave Koelmeyer
> http://blog.davekoelmeyer.co.nz
> GPG Key ID: 0x238BFF87
>

Re: in-line audio 'wav' files

[Jürgen Weber]

You might port these old plugins:

http://www.ecyrd.com/JSPWiki/wiki/AnyPluginToInsertArbitraryUrl
http://www.ecyrd.com/JSPWiki/wiki/IFramePlugin

Cheers,
Juergen

2016-10-03 11:38 GMT+02:00 MICHAEL HARBOUR :
> I use JSPWiki to compile notes about using a music digital-audio-workstation. 
> I
> produce 'wav' audio files.
>
> Is there a way I can embed a wav player in JSPwiki pages? That would help
> tremendously, rather than opening a player in a new tab in the browser.
>
> Many thanks in advance for any help.
>
> Cheers
>
> Mike