Not logged in. · Lost password · Register
Page:  1  2  3  next 

All posts by Falkor (32)

topic: Database :-(  in the forum: General Help and Support Features and Functionality
Avatar
Falkor #1
Member since Apr 2007 · 32 posts
Group memberships: Members
Show profile · Link to this post
Subject: Database :-(
I have now unfortunately received the news that for my wiki-system to live, I need to switch to a
database access (shared host) due to security measures.

In worst case this means that I have to let go of dokuwiki, which I have become extremely fond of.
Then of course, the question has occurred whether it is possible to make dokuwiki work with a
database backend?

I'm not too bad with php myself, but I understand that this can be quite a task. Even if possible,
is there a way to override the creation of files, and make it save in a database instead?

My first idea is to make a plugin that will override it, since I don't want to branch off the main distribution.
Not announcing that this will actually happen, but where should I even start? Will I find everything I need
in the /inc folder?

Would anybody else be interested in something like this?

//Falkor
topic: Is it possible to save and continue editing?  in the forum: General Help and Support Features and Functionality
Avatar
Falkor #2
Member since Apr 2007 · 32 posts
Group memberships: Members
Show profile · Link to this post
In reply to post ID 4780
There is such a feature.

When you press 'preview', the document is forcefully saved as draft.
I made a small plugin to view the source of the drafts via the 'admin'-page.

It is in 'alpha' and will only show the page source, not rendered page.
It doesn't work out of the box. I've only tested it on unix-like systems, and you have to edit the admin.php and getDrafts.php and
change YOURDOKUWIKIDIR to the filesystem directory of your dokuwiki directory.

You can find it at:

http://folk.uio.no/twhoffma/dokuwiki/draftlist.tar.gz

//Falkor
topic: ACL groups support in dokuwiki  in the forum: General Help and Support Features and Functionality
Avatar
Falkor #3
Member since Apr 2007 · 32 posts
Group memberships: Members
Show profile · Link to this post
In reply to post ID 4749
Mind you, if you're going to add 400 to a group, you might want to consider doing it from the command line.

The group-property is a part of the file user.auth.php.

With a bit of skill you could write a convert script that would add all of your users to the file (I'm assuming you want to authenticate from a flat file).

//Falkor
topic: Mail notifications to all registered users  in the forum: General Help and Support Features and Functionality
Avatar
Falkor #4
Member since Apr 2007 · 32 posts
Group memberships: Members
Show profile · Link to this post
In reply to post ID 4603
Actually, I once wrote a solution you may be able to use.

It's an action-plugin that sends notification mail to a certain group of users when a page is added to a namespace (I use it for that, but you could easily modify this to be an admin-plugin with post-form). My suggestion is that you could use one namespace for maintenance-messages, and have all users of a certain group being notified when you add a message to it.

Mind you, I have not tested this more then I found necessary - it works well to send out copies to people who normally do not read the wiki. My page is more of a complete news system.

It does not allow one to subscribe to all subnamespaces (e.g. news:*), only pages added in e.g. news. I'm planning on adding this with regex support at some later stage.

You have to check the "send notification mail" checkbox in the edit form (which only appears in the right namespaces - if it doesn't appear, but haven't setup the namespaces correctly) to actually send the mail. I'm guessing you could use group "" (empty) to send to all users of the wiki - but I have not tested this.

You can get it, (and use it at your own risk) from: http://folk.uio.no/twhoffma/dokuwiki/nssubscribe.tar.gz.

It works well on several namespaces, comma-separated - but as far as I know - not on several groups.


For your second problem, I would simply setup a rediect to a static html-page while you update the wiki. You definetly don't want any of the scripts on the wiki running when you upgrade. Say maintenance.html in your webroot, and redirect from your index.php file.

Good luck.

//Falkor
This post was edited 2 times, last on 2007-10-26, 14:25 by Falkor.
topic: Manager for User Registration  in the forum: General Help and Support Features and Functionality
Avatar
Falkor #5
Member since Apr 2007 · 32 posts
Group memberships: Members
Show profile · Link to this post
In reply to post ID 4160
I think that might be a little bit difficult.
As you might have noticed, you have to be admin to add new users. You'd have to circumvent several of the restrictions in place.

Since there isn't even an event when a user is registered (this you'd have to add on your own, and hence branch off the official dokuwiki -- not recommended), it is difficult to  intercept and set the new user to a specific group based on the editor that registered the user (given that you can even get around the user-registration issue). If you can get around this restriction, you could easily set the right restrictions to let new users of an editor only have rw-access to a specific namespace.

I'd probably solve it in a combination of an admin (managers allowed - the editors have to be managers) plugin and action plugins. You still have to get around the user registration problem - probably an ugly hack in an admin plugin, as you want to limit what field a manager can set on the user - e.g. not allowed to set groups, or at the very least check that the group he adds the user to are allowed. It will very quickly become quite complex.

I prefer the "keep it simple stupid"-tactic.

//Falkor
topic: [SOLVED] how to trigger some (or all) (syntax)-plugins on a string  in the forum: General Help and Support Plugins
Avatar
Falkor #6
Member since Apr 2007 · 32 posts
Group memberships: Members
Show profile · Link to this post
In reply to post ID 4260
Thanks a lot! This has been enlightening :-)

//Falkor
topic: [SOLVED] how to trigger some (or all) (syntax)-plugins on a string  in the forum: General Help and Support Plugins
Avatar
Falkor #7
Member since Apr 2007 · 32 posts
Group memberships: Members
Show profile · Link to this post
In reply to post ID 4248
Quote by chi:
And just another idea: If I understand you correctly, you`re about to implement a subscription system which sends the whole page as plain text via mail after a change. If that`s the case you don`t need to parse the thing again, you could also use the latest cached revision and strip all HTML tags from it.

That's a good idea. When is a revision is cached? I'm using a the IO_WIKIPAGE_WRITE event to trigger it and use the data that is in the event. As you might imagine it is imperative that it is the latest version that is included in the mail.

//Falkor
topic: [SOLVED] how to trigger some (or all) (syntax)-plugins on a string  in the forum: General Help and Support Plugins
Avatar
Falkor #8
Member since Apr 2007 · 32 posts
Group memberships: Members
Show profile · Link to this post
In reply to post ID 4242
Thanks for quick reply.

This is basicly what I'm looking for, but I'd like to avoid the whole xhtml if possible.
I guess the quickest and dirties way is to strip all html-tags afterwards?

If I were to remove some of the instructions, would that cause significant problems for p_render?
It's very important that the email sent is plain text, although it does contain a link to the page if one wish to read it in a
nicer format.

I'd really like to hear your thoughts on this, before I put [solved] in the subject.

Cheers,

//Falkor
topic: [SOLVED] how to trigger some (or all) (syntax)-plugins on a string  in the forum: General Help and Support Plugins
Avatar
Falkor #9
Member since Apr 2007 · 32 posts
Group memberships: Members
Show profile · Link to this post
Subject: [SOLVED] how to trigger some (or all) (syntax)-plugins on a string
Hi all,

I'm in need of a way to trigger either some or all plugins on a string (page) before I send it as email to some
subscribers (this is not the normal subscription, but a crude group-based subscription plugin I've made).

The reason is that I use the numbered_headings plugin, and it would make the some of the documents a lot easier to
read in pure text form.

Hope somebody can help,


//Falkor
This post was edited on 2007-09-27, 12:51 by Falkor.
topic: [SOLVED] Discussion full of spam ! (My discussion is full of spam, how can i protect, clear it ?)  in the forum: General Help and Support Plugins
Avatar
Falkor #10
Member since Apr 2007 · 32 posts
Group memberships: Members
Show profile · Link to this post
In reply to post ID 4111
If I remember correctly it is saved under metadata in .comments-files.

You can always turn it off, but it gets tedious after a while. I have yet to find a way to disable discussion by default, and enable with tag only. I have the same problem since I use the blog plugin as my simple newssystem on the frontpage of my wiki, and I really don't want the discussion to interfere (I use discussion for an internal discussion board).

//Falkor
topic: Discussion and Blog plugin to run seperately?  in the forum: General Help and Support Plugins
Avatar
Falkor #11
Member since Apr 2007 · 32 posts
Group memberships: Members
Show profile · Link to this post
Subject: Discussion and Blog plugin to run seperately?
Hi,

I have an issue that is driving me nuts. I'm currently using the blog-plugin for a news system that is not supposed to
have any form of discussion. It's simply a convenient way to post frontpage news.

However, the site also has an internal discussion page for issues to be taken up on the next meeting. For some reason,
the discussion-form seems to add to the edit field when I create new pages in the blog, and won't disappear even if I remove the ~~DISCUSSION~~ that is automaticly added.

Is there any way to make these play nice? I've tired most flags I found..

//Falkor
topic: Securing dokuwiki from hijacking  in the forum: General Help and Support Server Setup
Avatar
Falkor #12
Member since Apr 2007 · 32 posts
Group memberships: Members
Show profile · Link to this post
Subject: Securing dokuwiki from hijacking
I apologize if this ended up in the wrong category.

Hi,

I wondered how to secure dokuwiki the most. I'm unfortunately on a shared server, which means that anyone that can get into a user account on the system, can put a php-file in the webarea of that user, then run it through the webbrowser to create e.g. an admin account for dokuwiki. (Or worse, delete the whole thing).

Even if I can prevent anyone except the user that hosts dokuwiki and the webserver itself from seeing the datafiles by setting the right chmod restrictions, how to prevent a hijacking like this? Assume that I do not have any other mean than "plain" as an alternative to authenticate.

I'm imagining something like running a special apache process in somekind of jail for displaying the www_docs of the user hosting dokuwiki (is that even possible?) - which would mean that a hijacking could only take place if the hack-script was placed by the user hosting it in his own www_docs.

It's not a critical-wiki, but I cannot rely on someone quite as computer-savvy taking over for me when I leave the union. I already have automatic backup in place.

It was a frightening experience - as I whipped up the hijack-scripts in a matter of minutes.

//Falkor
topic: IO_WIKIPAGE_WRITE sent twice??  in the forum: General Help and Support Plugins
Avatar
Falkor #13
Member since Apr 2007 · 32 posts
Group memberships: Members
Show profile · Link to this post
In reply to post ID 3973
Hi Netsurfer,

I like the idea - but I'm sceptic to branch off from the official dokuwiki distro, if you know what I mean.

In my opinion, we should really have a better way to deal with this stuff when programming plugins - but
I'm guessing that andi and the other developers have far too many more important things on theuir hands to deal
with this now. Maybe I should add it to the wish-list, if there is one :-)

//Falkor
topic: List locked files?  in the forum: General Help and Support Features and Functionality
Avatar
Falkor #14
Member since Apr 2007 · 32 posts
Group memberships: Members
Show profile · Link to this post
In reply to post ID 3941
salto, and remember - the lock usually expires after 15 min (default?) or some other short time period.
Therefore I don't think there would be a huge demand for this - I do however find the listing of drafts useful on occasion, if I have forgotten what I did last.

The reason why this works for drafts is because it stores more information, while the .lock file only stores the username that locked it, (and uses the modification time of the file, I presume).

You could try using some of the techniques from the "Maintenance"-page if you need to clean out old locks and stuff.

//Falkor
topic: List locked files?  in the forum: General Help and Support Features and Functionality
Avatar
Falkor #15
Member since Apr 2007 · 32 posts
Group memberships: Members
Show profile · Link to this post
In reply to post ID 3936
I realize that I might be misunderstanding something.

What kind of locks are we talking about? I just tested by diffing the "find ./data -name '*.lock'  " result before and while editing a page in the wiki and there is a new file under ./data/lock/, but no new '.lock' files under any other directories.

//Falkor
This post was edited on 2007-08-29, 12:52 by Falkor.
Close Smaller – Larger + Reply to this post:
Special characters:
Page:  1  2  3  next 
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-09-16, 22:45:39 (UTC +02:00)