Not logged in. · Lost password · Register

All posts by jjoelc (13)

topic: Can a plug-in call the dokuwiki media manager?  in the forum: General Help and Support Plugins
Avatar
jjoelc #1
Member since Jan 2012 · 13 posts · Location: Amarillo TX
Group memberships: Members
Show profile · Link to this post
Subject: Can a plug-in call the dokuwiki media manager?
I'm starting my first (semi-) complex plugin, and part of it would be MUCH easier if my plugin can call up dokuwiki's Media Manager to browse to and upload files. Is this possible? I haven't had much luck in my searches.

Thanks!
topic: Autolink based off regex  in the forum: General Help and Support Plugins Plugin Wishlist
Avatar
jjoelc #2
Member since Jan 2012 · 13 posts · Location: Amarillo TX
Group memberships: Members
Show profile · Link to this post
In reply to post ID 33499
no promises or timeline, but one of our real developers is planning on an auto link plug in that should suit your needs. Wish I had more for you, but... hopefully you haven't given up..

Both of these are old, and don't have regex.. but could possibly get you by??
https://www.dokuwiki.org/plugin:autolink2
https://www.dokuwiki.org/plugin:autolink3

I have not tried them personally, just ran across them myself while looking into our auto link plug-in idea...
topic: Video plugin for HTML5 Video Player  in the forum: General Help and Support Plugins Plugin Wishlist
Avatar
jjoelc #3
Member since Jan 2012 · 13 posts · Location: Amarillo TX
Group memberships: Members
Show profile · Link to this post
In reply to post ID 35435
I have also released a html5 plugin called htvid (http://www.dokuwiki.org/plugin:htvid) that is mostly based off of the HTML5Video plugin listed earlier. It does accept 2 video files (an mp4 and an ogv) and falls back to flash for browsers that don't support the video tag. (using the JWPlayer from the "FlashPlayer plugin" (included in my plugin, so not dependent on having flashplayer installed) as a flash wrapper for the mp4 file)

It's pretty rough around the edges, but was hacked together as a one-off for our internal wiki. So if someone with a bit more time and skill is interested in adopting it, feel free to contact me.
topic: Timer-Function for TimeCard requested (Groupware service)  in the forum: General Help and Support Plugins Plugin Wishlist
Avatar
jjoelc #4
Member since Jan 2012 · 13 posts · Location: Amarillo TX
Group memberships: Members
Show profile · Link to this post
In reply to post ID 18254
I can see a couple of simple ways to do this... The problem with each of them is that the user would have the ability to simple go in and change any time stamp, at any time... Makes audit trails impossible (or at least, terribly difficult and manual labor intensive...)

what might be the simplest solution for you is to install something like PHProject to handle the timekeeping, and just use the wiki as a "gateway" to it. maybe use something like the iframe plugin to simply display the needed PHProject page inside the wiki? or just URL links to specific needed pages from PHProject, etc...

Good luck!
topic: Export DW tables as csv files. (action plugin to add "save as csv" button next to DW Tables...)  in the forum: General Help and Support Plugins Plugin Wishlist
Avatar
jjoelc #5
Member since Jan 2012 · 13 posts · Location: Amarillo TX
Group memberships: Members
Show profile · Link to this post
Subject: Export DW tables as csv files.
Given all of the utilities out there to convert .csv files to DW tables (or use them directly in DW, like the CSV plugin  http://www.dokuwiki.org/plugin:csv) this should be a relatively simple plugin, but my minimal PHP skils were last used almost 12 years ago, and likely are not up to the task, so I ask  for your help!

The way this works (in my mind at least) is the user simply surrounds a table in the wiki with a tag (<tocsv></tocsv> perhaps?) Any table inside this tag would have a button added next to it (small button similar to the "edit" button in each subsection) to convert the table to a csv file and send it to the user through the browser's regular "save file" function...

Looking at the CSV plugin's syntax.php file, it seems it would be reasonably easy to just reverse the order of processing in that plugin (taking the DW markup as source, and find/replace needed characters to spit out .csv) using php to serve out the file for the user to download is also relatively simple. That just leaves creating the button to be embedded next to the table to fire the process off.

Another possibility would be to use something like Jquery table to csv http://www.kunalbabre.com/projects/table2CSV.php to grab the HTML formatted table after DW has rendered the page, though to me this does not feel as "right" as using DWs existing infrastructure to do some of the work...

I'm willing to help in this as much as possible, though as I said my PHP skills are rather limited and probably out of date ;-)

[edit]
Some clarification on my reasoning for this...
To pick one example, we have a contact list set up as a table in our wiki. there is some overall management of course, but generally, the individual users keep this table up to date (when they move desks or get a new cell phone for example). Most of our users are not terribly computer literate. So I use FCKGLite as a WYSIWYG editor. This makes it much simpler for the users to make changes to tables, especially. With the turnover rate in our business, this table changes quite frequently. Using the CSV plug-in makes editing the table inside of the wiki either impossible (if using a linked file) or impractical to less savvy users (if using inline data) so I really need to keep the ability to edit the table in FCKGLite. However, it is incredibly useful to be able to grab that information as a csv file (on the fly, so you get the most recent version) to be imported into... well.. just about any other program... Thus, the quest to just have a button to send the user a csv file of the info in a table.
Hope that helps to clarify things more than it confuses them!
This post was edited on 2012-06-27, 17:29 by jjoelc.
topic: FCKGLite disable on per page or namespace?  in the forum: General Help and Support Plugins
Avatar
jjoelc #6
Member since Jan 2012 · 13 posts · Location: Amarillo TX
Group memberships: Members
Show profile · Link to this post
In reply to post ID 32646
Sorry for the looong delay in responding, had some fun arguing with Active Directory and a bad power supply :-)

To finally answer you, yes, your updates "edit.php" file did behave correctly with DWs RSS feature. Thank You!

I do still like the idea of some way to disable FCKGLite on a per page basis, but the ability to disable it per namespace is a big step in the right direction, and quite useful as well, so again... Thank you!
topic: FCKGLite disable on per page or namespace?  in the forum: General Help and Support Plugins
Avatar
jjoelc #7
Member since Jan 2012 · 13 posts · Location: Amarillo TX
Group memberships: Members
Show profile · Link to this post
In reply to post ID 32644
I renamed the original edit.php, but didn't change the extension or clear the dokuwiki cache...... I'm away at the moment, but will try again as soon as I'm back at the office and let you know.

Thanks again for the help... I know thanks won't buy you dinner (or even a beer), but I honestly do appreciate the effort!
topic: FCKGLite disable on per page or namespace?  in the forum: General Help and Support Plugins
Avatar
jjoelc #8
Member since Jan 2012 · 13 posts · Location: Amarillo TX
Group memberships: Members
Show profile · Link to this post
In reply to post ID 32637
Thanks!

I will try utilizing the INCLUDE plugin for those "difficult" plugins, I hadn't thought of that!

and as far as the new "edit.php" file... as soon as I replace it on my server, I start getting server error 500 responses... Here is the paste from the apache error.log file

[Fri May 18 10:09:39 2012] [error] [client 10.0.0.34] PHP Warning:  Invalid argument supplied for foreach() in C:\\Dokuwiki\\apps\\dokuwiki\\htdocs\\lib\\plugins\\fckg\\fckeditor\\extensions.php on line 13, referer: http://connect10/dokuwiki/lib/plugins/fckg/fckeditor/editor/fckeditor.html?InstanceName=wiki__text&Toolbar=Dokuwiki
[Fri May 18 10:09:39 2012] [error] [client 10.0.0.34] PHP Notice:  Undefined variable: image_extensions in C:\\Dokuwiki\\apps\\dokuwiki\\htdocs\\lib\\plugins\\fckg\\fckeditor\\extensions.php on line 24, referer: http://connect10/dokuwiki/lib/plugins/fckg/fckeditor/editor/fckeditor.html?InstanceName=wiki__text&Toolbar=Dokuwiki
[Fri May 18 10:09:39 2012] [error] [client 10.0.0.34] PHP Warning:  implode(): Invalid arguments passed in C:\\Dokuwiki\\apps\\dokuwiki\\htdocs\\lib\\plugins\\fckg\\fckeditor\\extensions.php on line 24, referer: http://connect10/dokuwiki/lib/plugins/fckg/fckeditor/editor/fckeditor.html?InstanceName=wiki__text&Toolbar=Dokuwiki
[Fri May 18 10:11:48 2012] [error] [client 10.0.0.34] PHP Fatal error:  Cannot redeclare class action_plugin_fckg_edit in C:\\Dokuwiki\\apps\\dokuwiki\\htdocs\\lib\\plugins\\fckg\\action\\edit.php on line 2535, referer: http://connect10/dokuwiki/doku.php?id=start

typo? Somewhere it thinks you are declaring it twice?? Sorry, I'm only minimally literate in PHP...

Reverting back to the original edit.php made the error go away, though.

__________________edit_________________
forgot to mention, this error happened when trying to load any page in dokuwiki, not just when trying to open the editor..
topic: FCKGLite disable on per page or namespace?  in the forum: General Help and Support Plugins
Avatar
jjoelc #9
Member since Jan 2012 · 13 posts · Location: Amarillo TX
Group memberships: Members
Show profile · Link to this post
In reply to post ID 32634
Thanks for the reply, but I guess I should have made my edit a bit more clear...

I DID find the field in configuration manager to have a namespace (or namespaces) use DW edit. and was glad to see it. At this point my question boils down to various methods of trying to assure plugins (or the RSS feed utility built into the DW syntax) are left in tact  across edits in FCKGLite. Then a feature suggestion for a method of disabling it on a per page basis.

Again, thanks for the reply!
topic: FCKGLite disable on per page or namespace?  in the forum: General Help and Support Plugins
Avatar
jjoelc #10
Member since Jan 2012 · 13 posts · Location: Amarillo TX
Group memberships: Members
Show profile · Link to this post
Subject: FCKGLite disable on per page or namespace?
I am wondering if there is a way to disable FCKGLite editor on a per page or namespace basis... If not, could you consider this a feature request? Something along the lines of ~~NOCACHE~~ or ~~NOTOC~~ tags on the page to force that specific page to be edited in DWedit mode would be really handy... ~~NOFCKGLITE~~ maybe?

Related to that, is there a way to include other plugin tags etc inside of FCKGLite? Do I simply need to escape them? place them in <nowiki> tags??  to pick a built-in example-- when a page includes an RSS feed using DW Syntax
{{rss>http://slashdot.org/index.rss 5 author date 1h }}
when the page is later edited in FCGLite, the feed results are converted into static links and the RSS feed is effectively removed. To be honest, I have not tried other plugins yet, but am expecting similar behavior...
.
.
later...
.
.
OK.. Before looking like an idiot, I decided to test with some plugins, and read the directions, LOL.. The RSS feed example above still behaved as described. I am able to enter the plugin from FCKGLite initially without issue... Save, and the RSS feed shows up on the page. Click edit again though and FCKGLite window only shows the output of the syntax, not the original {{rss>... markup.

I did find the field in configuration to disable FCKGLite by namespace.. Thank You! But I have to admit I still like the idea of a ~~NOFCKGLITE~~ or similar tag that can be added on a per page basis
topic: Use a different print.css only for specific pages?  in the forum: General Help and Support Templates and Layout
Avatar
jjoelc #11
Member since Jan 2012 · 13 posts · Location: Amarillo TX
Group memberships: Members
Show profile · Link to this post
Subject: Use a different print.css only for specific pages?
I'm just wondering if there is an easy way to use a different print.css file on specific pages in the wiki?

Specifically... I am using the IssueTracker plugin, and while the default print layout is usable, for those specific views, I would like to use a bit different print setup, just for the sake of readability.. I don't have any problem creating the print.css file I want... Just not sure what might be the most practical way of applying it to those specific pages, and not the rest of the wiki.
topic: Any way for Users to choose their own group?  in the forum: General Help and Support Installation and Configuration
Avatar
jjoelc #12
Member since Jan 2012 · 13 posts · Location: Amarillo TX
Group memberships: Members
Show profile · Link to this post
In reply to post ID 30019
Thanks for the input. I didn't have high hopes, honestly. I started teaching myself PHP back in the late 90's, but even at that time, I wasn't much more than scratching the surface.. I'd get myself into more trouble long before I made any progress, lol.

Like I said.. I know it is just asking to be abused in all but the smallest of organizations... (and if they are that small, why not just have an admin create the users and assign their group?) My particular company is right on that line.. Small enough to basically trust everyone to choose the appropriate user group (aside from admins, at least...) just large enough to make doing it manually make you start thinking of ways to even partially automate things :-)
topic: Any way for Users to choose their own group?  in the forum: General Help and Support Installation and Configuration
Avatar
jjoelc #13
Member since Jan 2012 · 13 posts · Location: Amarillo TX
Group memberships: Members
Show profile · Link to this post
Subject: Any way for Users to choose their own group?
I know.. This sounds counter intuitive, but I'm wondering if there is any way to have users choose their own group at registration?

Here's how I imagine it:
Admins or managers get manually configured in the system
regular users from each department register like normal, but below the password fields would be something along the lines of: "What department are you in?" with a dropdown list with options for "Sales",  "Engineering", etc. The user would then be assigned to that group automatically... each group would have exclusive write access to their own pages, but read-only for other sections.

I know such a system is rife for possible abuse, but for my purposes "secure-enough"... I won't be terribly disappointed if it is not possible, just curious :-)

Thanks!
Close Smaller – Larger + Reply to this post:
Special characters:
Special queries
Go to forum
Imprint
This board is powered by the Unclassified NewsBoard software, 20150713-dev, © 2003-2015 by Yves Goergen
Current time: 2019-08-21, 17:55:49 (UTC +02:00)