I have been trying to upgrade to ver. 4_4_3139 from the previous one.
However, the site is down and there is an error message:
include/db.php line 916: unserialize() [function.unserialize]: Error
at offset 0 of 59 bytes
Is there anything else I need to do apart from copying the files? I
have not found any other instruction.
Thank you very much in advance!
Zbigniew Szalbot
> I have been trying to upgrade to ver. 4_4_3139 from the previous one.
> However, the site is down and there is an error message:
> include/db.php line 916: unserialize() [function.unserialize]: Error
> at offset 0 of 59 bytes
The plugin configuration was broken before this release; it looks like
you are using a plugin that uses an invalid 'config' string. Since
those had no functionality before this release IIRC, you can just
clear that string from the 'plugins' table in the MySQL database.
Bye,
Axel.
On 26 February 2012 18:00, Axel Dörfler <axel.d...@gmail.com> wrote:
> The plugin configuration was broken before this release; it looks like
> you are using a plugin that uses an invalid 'config' string. Since
> those had no functionality before this release IIRC, you can just
> clear that string from the 'plugins' table in the MySQL database.
Thanks a lot, Axel. I did not know what to do, so I figured I would
copy db.php from my older installation. Then the same message appeared
but this time it referred to (I believe) plugin_functions.php. When I
copied its previous version, the site went back to normal...
Zbigniew Szalbot
Mixing different versions is usually not really a good idea, and can
lead to subtle or not so subtle bugs in the end result, so it would be
advisable to fix the database - do you need help with that? If so, do
you have a tool like phpmyadmin?
Anyway, we may want to let unserialize() fail silently, and maybe put
a message to the log?
To David: I don't know if those are ready to be used yet; I only fixed
the DB based config mechanism itself :-)
Bye,
Axel.
On 27 February 2012 09:31, Axel Dörfler <axel.d...@gmail.com> wrote:
> Mixing different versions is usually not really a good idea, and can
> lead to subtle or not so subtle bugs in the end result, so it would be
I fully realize that and would be happy to change it.
> advisable to fix the database - do you need help with that? If so, do
> you have a tool like phpmyadmin?
> Anyway, we may want to let unserialize() fail silently, and maybe put
> a message to the log?
I looked at the plugins table and not sure what to remove from there.
No unserialize() instance in there. Please find the plugins table dump
attached.0
Thank you for your help!
Zbigniew Szalbot
The unserialize() comment wasn't directed to you, but rather the other
RS developers.
The 'slideshow' plugin seems to have a 'config' string set. Just clear
that one, and the current version of RS will work as expected.
If you don't have phpmyadmin, you would do this like this, just to get
you the basic idea:
UPDATE plugins SET config=null;
Bye,
Axel.
On 27 February 2012 10:11, Axel Dörfler <axel.d...@gmail.com> wrote:
> The 'slideshow' plugin seems to have a 'config' string set. Just clear
> that one, and the current version of RS will work as expected.
A great many thanks for this one! I never really managed to get the
slideshow plugin to work so I deactivated it and purged its config.
Both files from the /include directory have been updated and the
system works as expected. Thank you very much! :)
Zbigniew Szalbot
Yes, I think this method works well to eliminate the need to manually
modify plugin config files on the server, and I've set up several
examples (in current included plugins) of how to create the setup.php
pages using form-creation functions in plugin_functions.php.
Personally I think these functions make it very easy to create these
setup pages, and storing configs in the db makes it easier to manage
plugins via svn. This was really just me fixing up some work that
Brian Adams did years ago but wasn't fully working. There was no
documentation on that feature, so I did my best to make it work as I
thought he intended. I'm sure there are improvements that can be made
still, but I've been using this method more and more with no major
issues other than sometimes not having a premade function for a
certain type of config field I'd like to build.
This is all related to the longer-term goal of keeping cleaner base
code, and cleaner plugin code (in terms of svn checkouts). With
totally clean checkouts, we could eventually work out the ability to
do manual or automatic svn checkouts or updates via the web interface,
which would be especially useful for plugins which rely on specific
version of RS, or have their own 'release schedule'.
It would be great if you could update the wiki documentation on
Writing Plugins.
Thanks,
Tom
> --
> You received this message because you are subscribed to the Google Groups "ResourceSpace" group.
> To post to this group, send email to resour...@googlegroups.com.
> To unsubscribe from this group, send email to resourcespac...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/resourcespace?hl=en.
>
--
Tom Gleason
Vice President, Engineering
Colorhythm LLC
http://www.colorhythm.com
Main Office: +1 415-399-9921
Fax: +1 253-399-9928
Mobile: +1 347-537-8465