Activity for Mark Grimshaw
-
Mark Grimshaw committed [r6372] on SVN
Minor edits to screenshots documentation.
-
Add help topic links for Admin|Bibliographies...
-
Add an Admin|Images help topic.
-
Update web documentation Help topics|FAQ.
-
Update website documentation for preferences (add information on publication lists).
-
Update website documentation for configure (remove warning about non-user configurable timezone).
-
Update website documentation for publication lists.
-
Update website documentation for publication lists.
-
:)
-
Minor amendment to Carambola template.
-
I've been doing this for the last few days—various configurations of sessions and session timeouts—and all seems fine. I'm ready for a release.
-
Today's SVN, fixing my code, works fine.
-
CHANGELOG: typos etc.
-
All seems fine now.
-
. . . and it seems the logging out of publication lists is working.
-
Ensuring publications list/logging out to read-only, works with browserTabID.
-
I made a modification ot DATE.php. When viewing the user-timezone adjusted date for resources, CLOSE etc., ensure that formats such as Asia/Hong_Kong are accounted for. That is, if the list of all timezones includes "[Asia/Hong_Kong] => Asia/Hong Kong" (note the difference), and $tzPriorityStack contains the user timezone [1] => Asia/Hong_Kong, then that user timezone is discarded when the array_intersect is applied. No longer. Perhaps there's a more elegant solution, but this works. All seems to...
-
Update a hint message.
-
Ensure only registered users can read news.
-
1. Minor typo causing a crash when viewing user registration details.
-
Yes. resoutce timestamps are now UTC. Mark On 23 Apr 2026, at 16.12, Stéphane Aulery lkppo@users.sourceforge.net wrote: And do you see the shift of date? [v5bugs:#740] Browsing a publication list or browsing as a readOnly user randomly bumps back to the login screen Status: wip Target: Unknown Found in: Unknown Created: Mon Mar 30, 2026 01:13 AM UTC by Mark Grimshaw Last Updated: Thu Apr 23, 2026 02:08 AM UTC Owner: Stéphane Aulery Hi Stéphane, I've puzzled over this for some time and can't figure...
-
So far so good. No problems to report this end after upgrading. Mark
-
Update documentation (especially styles help file) for forthcoming 6.13.0.
-
Update all standard bib styles to WIKINDX_COMPONENTS_COMPATIBLE_VERSION['style'] == 31
-
Update the default APA style files to WIKINDX_COMPONENTS_COMPATIBLE_VERSION['style'] == 31
-
Update WIKINDX_COMPONENTS_COMPATIBLE_VERSION['style'] to 31 to account for structural changes to bib styles.
-
Fix an issue in MYWIKINDX email notification where the user's preference was not stored.
-
Minor correction to APA format.
-
Minor corrections to CHANGELOG.
-
Ensure users who are members of a group bibliography, can select that bibliography when importing resources or adding/editng a new one.
-
ReadOnly session not kept throughout lifetime
-
. . . and just to clarify, this is actually an issue with session retention not preference saving. For example, a term put into QUICKSEARCH should be retained and re-presented throughout the session but is not.
-
However . . . perhaps fix the timestamp issue first as (with my time difference in the mysql database) this might affect the retention of session rows.
-
Partly . . . Conditions: PHP sessions and relaunch browser. 1. If logged on as registered user (sessionUserId != 0), switching to readOnly now correctly writes a row to session with sessionUserId == 0. (Previously kept the registered user sessionUserId.) 2. Preferences not set upon change. for a readOnly user Upon Preferences save, a new row is written to the session table (presumably with the defaults). No changes in preferences are saved.
-
. . . but a useful one! ;)
-
Update the CHANGELOG.
-
Seems fine with initial testing.
-
Ah! Thought you had done it. I've discovered a clue pointing to the solution. It is, of course, nothing to do with browsers. I've been testing using standard PHP sessions written to the session table. The issue is to do with one browser previously having used registered user before shifting to readOnly and the other (on opening the browser) starting in readOnly mode. 1. In read only mode, preferences are written and saved when the user had been logged on as a registered user then logs out and enters...
-
A few days later and it's now working on Chrome but not on Safari. Very strange.
-
Complete the process of implementing the new resource_misc.publicationStatus field in the adminstyle plugin and to bibliographic and citation style formatting.
-
Begin the process of implementing the new resource_misc.publicationStatus field in the adminstyle plugin and to bibliographic and citation style formatting.
-
Sounds like a significant problem. I've done a quick check with the latest SVN and all seems fine. Arabic (multiple versions I think) is listed—I chose one or two of these without the issues previously reported. Mark
-
Hmmm. Interesting. It works on Firefox but neither on Chrome nor Safari (even an old Opera). I tried closing all browsers and restarting. Same thing: Firefox is fine, the others not.
-
For selected resource types (mainly academic, text based), the publication status can now be set (when creating or editing a resource) and it will display for those types when displaying the resource. There are 6 types of status ranging from published to in preparation.
-
Malformed strings in message files cause crash
-
ReadOnly user's preferences not saved
-
Malformed strings in message files cause crash
-
Add resourcemiscPublicationStatus to resource_misc table. This will (eventually) account for the publication status of the resource to be used in the bibliographic formatting of the resource. Values are TINYINT(1) with 0 (default) == published, 1 == in press, 2 == accepted, 3 == under review, 4 == submitted. I will work on this over the next few days.
-
Write Timezone setting to session for a readOnly user's preferences.
-
Ensure user's timezone is in the CLOSE footer.
-
Update CMS hooks documentation for the new getPubList hook.
-
CMS hooks: added getPublist as an action. This will retrieve the resources in the defined publication list for insertion into a CMS or website.
-
Update CHANGELOG
-
a) change the hint in Admin|Configure|General display
-
Ensure browser_tab_id table has autoupdating DATETIME.
-
If no word is input for QUICKSEARCH, ensure there is a valid error message.
-
Try another solution to #740 re session_gc().
-
OK. Let's leave it.
-
If using browserTabID, fix an issue that caused moderated new user registration to fail (new user was unable to log on).
-
Amend an incorrect hint message.
-
SessionHandler::gc() permission denied
-
Updatedatabase 140 does not appear to have worked in all cases: repeat.
-
What about putting this (with a check for pre-existing value) after the two if() statements: $maxSessionNotAuthLifetime = $db->queryFetchFirstField(" SELECT configInt FROM config WHERE configName = 'configSessionNotAuthMaxlifetime'; ") ?? PHP_INT_MAX;
-
ALTER TABLE session MODIFY COLUMN sessionLastAccessTimestamp DATETIME NOT NULL DEFAULT current_timestamp() ON UPDATE current_timestamp(); run by hand works. So, not sure what happened during update. What is the type on your database? I will try changing again with update code.
-
And the lag of 6 hours also occurs on MariaDB. Interestingly, resource_timestamp timestamp fields are also datetime and also lag 6 hours behind. I guess it has something to do with changing timezones on my laptop moving between Denmark and China. timestamp responds to the server timezone setting, datestamp does not. I notice the mysql 'system time zone' variable is set to CST which is . . . 13 hours behind . . . . . . whereas the mysql server 'time zone' variable is set to 'SYSTEM' (in effect CST)....
-
And the lag of 6 hours also occurs on MariaDB. Interestingly, resource_timestamp timestamp fields are also datetime and also lag 6 hours behind. I guess it has something to do with changing timezones on my laptop moving between Denmark and China. timestamp responds to the server timezone setting, datestamp does not.
-
The random logging out is solved. The issue is now the lag . . .
-
And the lag of 6 hours also occurs on MariaDB.
-
Some things I notice (MySQL database): session has type TIMESTAMP for sessionLastAccessTimestamp session_browser_tab_id has type DATETIME for sessionbrowsertabTimestamp session.sessionLastAccessTimestamp keeps track with current local time session_browser_tab.sessionbrowsertabTimestamp lags 6 hours behind current local time session.sessionLastAccessTimestamp . . . update 140 should have modified the type to DATETIME . . . but this did not happen (see 1.)
-
#740: Part fix:
-
Got it!
-
I did something similar by commenting out the line at 396 (execution of the SQL delete statement). Everything works as expected (no booting back to login). I've been looking more closely at the SQL to delete from session_browser_tab but still puzzling. I think I need a separate SQL for deleting nonAuth rows as a) there is never a usersId in the users table of 0; b) sessionbrowsertabId of 0 simply means this a nonAuth access; so c) there is no need to join the users table: if sessionbroswertabId is...
-
Browsing a publication list or browsing as a readOnly user randomly bumps back to the login screen
-
Normal sessions as a readOnly user seem fine. With browserTabID, it seems to be something to do with SESSIONHANDLERS::gc() and the condition in the SQL at line 379. It could be something to do with TEMPSTORAGE line 66. And I have noticed something curious: a new row in the session table is written with the local(host) timestamp; a new row in session_browser_tab is written with the local(host) timestamp minus 6 hours. The database tables are created with the same timestamp protocols. Mark
-
Minor tidying up: when browsing random metadata and ideas, ensure the next (and, for ideas, also the previous) icons display the correct ALT text instead of e.g., 'Next resource'.
-
Browsing a publication list or logging on as a readOnly user randomly bumps back to the login screen
-
Minor improvements to BIBTEX page parsing for imports.
-
When viewing a single idea + subidea(s) from a list, the 'Return to list' link now returns to the previous place in the list (rather than the start of the list). Additionally, when viewing the list, make each group of idea + subidea(s) more distinct.
-
Add a SF bug ID to CHANGELOG.
-
When compressing a list of resources with attachments, the resulting zip file can not be downloaded.
-
When viewing a single resource from a list, the 'Return to list' link now returns to the previous place in the list (rather than the start o the list).
-
Update requirements and install documentation.
-
Update install documentation.
-
Update requirements documentation.
-
Update preamble documentation.
-
Improvements to comments re the last commit.
-
Correct the order of publication list front page display to resource timestamp rather than publication year—this matches the typical display of the WIKINDX front page and ensurees that newly added entries in the publication list that are missing a publication year are actually displayed.
-
When exporting a DOCX file from a list, ensure the interim DOCX folder is deleted after DOCX creation.
-
If searching a list and compressing attachments to a zip file, the zip file can now be successfully downloaded.
-
Hi Joachim, Re the first point, I will have to leave you in Stéphane's capable hands. Re the second point: this should be fixed in the latest SVN. Regards, Mark
-
Tidy up CHANGELOG
-
Fix an error adding/editing users where there are no resources with creators #737.
-
Cannot create a new user
-
OK. The following should fix the issue then (I assume you have access to the code): Replace the line at 1024 with: if (array_key_exists('creatorId', $this->vars)) { $this->formData['creatorId'] = $this->vars['creatorId']; } And, so you don't have the same issue editing a user, do the same with the line at 1106. That should do the trick. The issue is my fault—I didn't check for the existence of resources with creators when adding/editing users. If you have such resources, you can then assign the new...
-
Thank you Mikhail. That helps and I now think I know what is happening. Do you have the 'User is creator' select box in the add user form? I suspect not (i.e. you have no resources added or resources with creators). Mark
-
OK. A 500 error can be quite unspecific as to its cause. Can you try the following please? Turn on error reporting in WIKINDX: Admin|Configure . . . Debugging "Print PHP errors and warnings to the screen." Is there now a more specific error message on the screen when you try to add a user? Check for error messages in the server's error log. Mark
-
Thanks Mikhail. PHP and WIKINDX version match mine. I added a user 'julia' without email enabled entering just password and email address—the user was created without issues. Are you adding other details (the second row of the form)?
-
Hello Mikhail, Sorry to hear you are having problems—thank you for reporting. Can you duplicate here the exact username you are trying to enter? On the form for adding the new user, do you see this message? "Because email is enabled, a new user will be emailed a link inviting them to enter their own password." Or are you able to enter their password yourself? Mark
-
Fix an error in DOCX export related to the CODE HTML entity.
-
Bug fix in CITE.php (ensure an expected array is an array).
1 >
