Serendipity Forums

I just released the 1.6 version.

It has some improvements, but mainly adds support for backend working. It now has a sidebar link to get access to view, approve, insert and change events. The database administration panel has moved there also, but main admin stuff, like approve, change, erase, remains possible in frontend too.
There are some changes and bug fixes. Please make sure you read the Readme page!
Just wait until it is published on Spartacus (>24h).

@Garvin, you got a private message!

Ian

btw, I am really interested to get some feedback about the iCal thing in the WildWideWeb...

Hello Timbalu!

Any chance that we could see database independent version of your plugin at next release? It seems just like the thing needed for one of the sites I'm running, but due being very deeply entrenched in MySQL and myself running Postgres exclusively it doesn't fit the bill as such yet.

I had some success on 'porting' it over at version 1.4 but time was on short supply and only got as far as making the calendar show up nicely enough, adding events 'crashed' on MySQL calls.

I might have some time later to try porting myself but due my nonexistent PHP-skills the changeset will be pretty localised to my installation

Hi!

That's a good idea; I wasn't even aware it used MySQL specifics.

From what I see it would need:

* use a PHP time() timestamp instead of SQL NOW()

* Replace UUID() with...whatever. I haven't ever seen a UUID() call.

(* is "REPLACE" supported by PostgreSQL?)

* reomve mysql_errno() calls, instead check if serendipit_db_query is a string result instead of array

* remove mysql_query calls. We have serendipity_db_query, usage of direct DB function calls should always be avoided. Sorry that this slipped my attention.

* Remove lock table calls, or make them mysql-only by checking if serendipity['dbType'] is a mysql one

* Remove DATE_FORMAT and use PHP functions for this

* Use normal UPDATE statements, no UPDATE LOW_PRIORITY

* Remove auto-increment setting calls, this should't really be necessary to numberate all events following each other?

Best regards,
Garvin

Based on work I did with another project postgres timestamp datatypes should be fairly usable for the dates.

If I remember right, REPLACE needed substitution and some extra logic in implementation, but nothing too big.

-Reko

Hi

Well, Garvins recommendations possible should do, but myself I haven't got any experience with postgres, so I can't help. Some of the very specific things like LOCK and UPDATE LOW_PRIORITY don't effect the main functions. You dont need them really. The MySql UUID() is replaced with php function create_ical_guid(), if not available with database. The 2 remaining mysql_query calls just check if the table exists, possible usable with the s9y query functions too. If you are done, you could send me your opinions to do it better next time, please.

Regards,
Ian

Hi!

I don't use the cal plugin myself, but if I find some time I could try to rewrite the functions and then someone with postgresql and mysql would need to test if the plugin still works?

Regards,
Garvin

Hi!

Sorry, I have to give up on the plugin. Its date methods are to complex for me to carry over to postgresql, mostly because it uses "date" column types that would require int-columns, but I think converting it would destroy existing data, so a migration would need to be executed.

Also there are too many mysql-specific function calls in there instead of calls to the s9y API, which I cannot translate without the knowledge of how the plugin works.

I've added a "MySQL-only" to the title of the plugin to show that for SQLite and PostgreSQL users in the future.

Thanks a lot, Ian, though for providing this complex plugin to MySQL-users, I really see a lot of work/time spent on this plugin

Best regards,
Garvin

I know what you mean...!

Ian