Not logged in. · Lost password · Register
Forum: General Help and Support Development RSS
Should plugins use session_start() ?
Avatar
og #1
Member since May 2006 · 436 posts · Location: Bayern
Group memberships: Members
Show profile · Link to this post
Subject: Should plugins use session_start() ?
I recently found plugins having session-handling code and wonder if this is the way to do?
Most of the time it was sufficient to comment out the calls to get those plugins to work (e.g. database2). Maybe this code is from ancient DW versions, where a global session-handling was not implemented?!

Well, my question is more generic: How should session-data be implemented, when a plugin needs to keep state over several calls or whilst login of user?

I found this information, in an other plugin:
Start session customization
(Available since release 2014-05-05 “Ponder Stibbons”)

Dokuwiki starts (in inc/init.php) a session prior to the plugins.


Is there a developer note about how to permanently (for the time of the browser lifetime) store data in session, or has this to be done by other techniques?
Oli...
This post was edited 2 times, last on 2017-08-01, 16:29 by og.
Avatar
andi (Administrator) #2
User title: splitbrain
Member since May 2006 · 3522 posts · Location: Berlin Germany
Group memberships: Administrators, Members
Show profile · Link to this post
DokuWiki opens the session in inc/init.php. After some things are initialized it is closed again. This is because PHP locks the session and this session lock may halt background requests (like images, ajax, etc).

Depending on when your plugin runs, the session might already have been closed. You can still read a closed session's variables but writing will have no effect. If you need to write to it, you need to call session_start() again, use the session as usual and close the session with session_write_close again.

Please feel free to open a new page on session handling in the developer manual.
Read this if you don't get any useful answers.
Lies dies wenn du keine hilfreichen Antworten bekommst.
Avatar
og #3
Member since May 2006 · 436 posts · Location: Bayern
Group memberships: Members
Show profile · Link to this post
Ok. I still thinking about if it is a good idea to use session-variable in my case, or not. Currently it is used to keep state. For example the database2 plugin stores the live-settings of the user (how many rows to show from now on, filtering/sorting settings) inside a session variable.

Of course, this is what sessions are made for in normal web-applications. But it could also been done using POST params and carry options over each request. What would you prefer?

P.S.: Sure, i will create a session-handling page. I would think it fits here
https://www.dokuwiki.org/development#the_development_manual
so i prepared a page
https://www.dokuwiki.org/devel:session_handling
If you're comfortable with it, i can add content.
Oli...
Avatar
andi (Administrator) #4
User title: splitbrain
Member since May 2006 · 3522 posts · Location: Berlin Germany
Group memberships: Administrators, Members
Show profile · Link to this post
Passing all params by URL params can get complicated when there are lot of them... OTOH url parameters make it easy to bookmark the current state or link to it. Both are valid approaches.

Yes, please go ahead and add content to that page.
Read this if you don't get any useful answers.
Lies dies wenn du keine hilfreichen Antworten bekommst.
Avatar
og #5
Member since May 2006 · 436 posts · Location: Bayern
Group memberships: Members
Show profile · Link to this post
Currently i do not see any advantage in putting simple single-byte states (filtered row, sort-order, current page, number of rows per page, etc.) in a session, so i rewrite this to CGI-Params. The only drawback with CGI is, when using POST-method, the user gets strange results and messages when navigating through browsers page-histroy.

But the most important thing i had to solve is, how to prevent resending the same add/edit or delete command for a record. This is currently a problem in my plugin, because using browsers back-button causes it to resend form-data which will replay the last action.

I need a way to add some kind of one-time-seed to ensure a handled action cannot be done twice. Sessions are no solution here, either. Any idea on this?
Oli...
This post was edited on 2017-08-02, 21:59 by og.
Close Smaller – Larger + Reply to this post:
Verification code: VeriCode Please enter the word from the image into the text field below. (Type the letters only, lower case is okay.)
Smileys: :-) ;-) :-D :-p :blush: :cool: :rolleyes: :huh: :-/ <_< :-( :'( :#: :scared: 8-( :nuts: :-O
Special characters:
Go to forum
Imprint
This board is powered by the Unclassified NewsBoard software, 20150713-dev, © 2003-2015 by Yves Goergen
Current time: 2020-02-17, 23:44:07 (UTC +01:00)