Well I've already upgraded to the latest version (1.4.3 [10393])...NOT a nightly build! I guess I should have waited a bit...Go figure! lol

None-the-less, the upgrade went fine - but I'm now experiencing an unrelated bug (I think) - should I post elsewhere or do something different?

The bug:
(it appears when adding a link to a zenpage page, if the link contains an ampersand (&), such as in a query string, or in the "title" it doesn't display as a link - just text. A plain link works fine.)

Please best don't mix topics within a topic, it gets a bit inconvenient then to search etc. Where did you add a link how? Please also read the note about encoding on the release post.

I read the note on encoding but not sure I understand it...when I add a link using TineZenPage and the link isn't even close to being right...so then I use the link icon and paste the link that I know works...which includes a query string - and that doesn't work...

The note means Zenphoto stores text with special chars like ampersands in plain text unencode. We had a similar report on a ticket regarding image links: http://www.zenphoto.org/trac/ticket/2199

But we are so far not able to reproduce this. I tested including links to a page and an article via tinyZenpage and all works as expected (link is on that ticket). What is not right for you. Please post details and best a link.

If I create a new page and add a link - it works. However, there are some existing pages and links that, after the upgrade, are just text and I can't seem to fix them...but there are some existing links that still work...

However, if I copy the entire page to a new page - it still doesn't work but if I copy just the link to a new page it works...weird...

Link on homepage is fine:
http://www.mikemartinelli.com/
The link is:
Dynomax VT REVIEW!

But that same link on another page is just showing as text:
http://www.mikemartinelli.com/index.php?p=pages&title=ascmclaren-information

Same text:
Dynomax VT REVIEW
(towards bottom)

This page is all messed up - links and images:
http://www.mikemartinelli.com/index.php?p=pages&title=DadsLx5.0

Can i go directly into the DB to fix things?

Existing links may have been improperly encoded when they were created. The only solution for this is to either fix the data in the database or delete and re-create the links.

I tried deleting and re-creating but that didn't work...I'll just manually go into the database and do whatever I need to do...

Do I just delete them from the database then re-create in ZP? Or is there something else I need to do in the DB?

Thanks,
Mike

Just edit the data so that the links are not html encoded.

Got it thanks!

You should be able to do this via TinyMCE's html source view as well.

I just ended up doing it all in the DB...so far so good...hopefully I don't experience any of the canary mismatch errors anymore!

Errored again...That didn't take long. At least this time my css loads - ZERO content or images other than the background layout...weird. Restarting apache brought it back as usual.

Exact error:
[Wed Jul 11 17:27:35 2012] [error] [client xx.xxx.xxx.xxx] ALERT - canary mismatch on efree() - heap overflow detected (attacker 'xx.xxx.xxx.xxx', file '.......zp-core/functions-basic.php', line 877), referer: http://www.mikemartinelli.com/colorbox.css

What's the deal with colorbox this time? I know there was a path change with the new version of ZP but I couldn't get colorbox to work through ZP so I changed it up a bit using the path above...worked before and works fine now...

ZP version 1.4.3 [10393]

I'm also seeing some new debug-log entries that I didn't see before...

{Tue, 10 Jul 2012 23:10:39 GMT} Zenphoto v1.4.3[10393]

Backtrace: WARNING: Cannot modify header information - headers already sent by (output started at ......zp-core/zp-extensions/zenpage/zenpage-admin-functions.php:194) in ...........zp-core/admin-functions.php on line 109 header called from printAdminHeader (admin-functions.php [109]) from admin-edit.php [120]

Also this one:
{Wed, 11 Jul 2012 02:07:08 GMT}

Backtrace: NOTICE: Undefined index: HTTP_USER_AGENT in .......zp-core/zp-extensions/hitcounter.php on line 158

hitcounter::load_script called from call_user_func_array (unknown) from zp_apply_filter (functions-filter.php [150])
from index.php [71]

Here is what I found from a search on the cannary mismatch error:

http://www.suspekt.org/2008/10/12/suhosin-canary-mismatch-on-efree-heap-overflow-detected/

Not at all sure what this means, though.

"cannot modify header information" errors are almost always the result of up-stream errors.

The one with hitcounter seems strange, I do not know why there would not be a user agent specified. But that code is only invoked if the option hitcounter_ignoreSearchCrawlers_enable is set for hitcounter.

Yeah I've read a lot about the error - didn't get too far with server changes...figured I'd try to figure out what is triggering it on the ZP side...

don't know what would cause the header info or hitcounter errors either...prior to the upgrade I didn't have any debug errors...

Since so many people had problems finding their server logs we made Zenphoto log the errors it can. This is new to 1.4.3, so you would have seen these errors only in the PHP error log on prior releases.

The canary-mismatch seems to be either a bug in PHP or in the suhosin patch. Seems some debate as to which. I would presume that if it is a PHP issue it is caused by large scale memory use. Maybe the kses examination of input data creates more strings than PHP can handle. It does sound like there is an IP address in the message. Is that an address you are familiar with?

Regarding the user agent: Isn't it possible to hide or not send that via privacy browser extensions? (Just a wild guess)

The IP addresses vary - my guess is they are just visitors IP's - I see mine in there when I'm playing around too...I also see the same ones that ZP is logging as well.

What a mess! lol

I meant each browser sends a user agent (type of browser or bot etc). For some reason that not being sent or masked it could somehow confuse maybe...as said a very wild guess.. You are really the only one we ever heard having this error.....At least you take if with a bit fun..;-)

Well there is nothing else I can do but have fun with it. At least its not a client and just my personal site.

I appreciate the continued help. I'm sure I will be back reporting something. Ha

Beating a dead horse I know but talking about things ALWAYS helps!

BUT, I guess the biggest question I have is why isn't this happening with other ZP installs I have? I have a client that gets more traffic than me with regular updates...that is version 1.2.8 and is always super smooth...All on the same server...

It ONLY happens on the www domain of my site...not any other sub-domains...weird...There has to be something specific going on that I can't figure out...