wrong url-rewriting using /index.php?/frontpage about serendipity HOT 31 CLOSED

Thanks for the report!

I can confirm this. The sql-error shown results from a wrong LIMIT. I'll have a look, but as it is nowhere linked wrong (right?) I don't think it's urgent,

from serendipity.

Not urgent, but it is described in the german manual. If someone trys to us it (like i did), he/she will get this errors.

Don't know, which other parts of the code are affected from this bug or where the link from the manual is described too.

from serendipity.

Could you please point us to to the manual part, where you say this is described like this?
I think this is definitely not a bug in Serendipity itself, is is a bad typo in that manual. But I can't find that...

It has IMHO always been used as index.php?frontpage to resolve properly in pagination to index.php?/archives/Px.html or /archives/Px.html with mod_rewrite.

from serendipity.

It is described in https://github.com/s9y/Book/blob/master/serendipity.pdf?raw=true on page 415.

from serendipity.

Ah yes, ...the book ;-)
We need an appended errata or update it fluently and generate a new pdf.

@garvinhicking

What shall we do about it, if this is a typo?

from serendipity.

Even though it's a typo, it's a bad bug that 1. s9y shows a SQL error and 2. that it doesn't simply go to the 404 page or the index page or whatever.

So the actual problem is that a URL like this should never cause such an error, and ideally we'd try to catch this URL as going to the frontpage as well.

No matter how URLs are formed, it should never result in SQL errors. I wonder why it has a negative LIMIT statement there. I guess it's because of the "Stable Page order" patch?

Regards,
Garvin

from serendipity.

Just a comment.... I did not get any error or even the SQL error, since I used 1.6.1 stable to test this.
The page on P2 was just empty.

from serendipity.

guess it's because of the "Stable Page order" patch?

Not likely. The stable archive order uses arguments given to the function. But quite possible that in a step before, those arguments are wrongly filled. I'll see if I can debug it in 2.0.

from serendipity.

Maybe bauigel has some other plugins enabled that influence this, i.e. categorytemplates, customarchive, entrypaging or others. Bauigel, can you please mention all active installed event plugins? Maybe you can also temporarily disable additional event plugins to see which one might cause this.

from serendipity.

Have fun ;) (for me) there is nothing that affects the url-structure.

serendipity_event_jquery
serendipity_event_openid
serendipity_event_xmlrpc
serendipity_event_spamblock_bee
serendipity_event_spamblock_bayes
serendipity_event_emoticonchooser
serendipity_event_imageselectorplus
serendipity_event_trackback
serendipity_event_livesearch
serendipity_event_freetag
serendipity_event_typesetbuttons
serendipity_plugin_twitter
serendipity_event_weblogping
serendipity_event_spartacus
serendipity_event_autotitle
serendipity_event_gravatar
serendipity_event_contactform
serendipity_event_staticpage
serendipity_event_google_sitemap
serendipity_event_dbclean
serendipity_event_entrypaging
serendipity_event_textile
serendipity_event_head_nugget
serendipity_event_commentspice
serendipity_event_delayed_trackbacks
serendipity_event_lsrstopper
serendipity_event_lightbox
serendipity_event_dashboard

from serendipity.

I have disabled serendipity_event_entrypaging, but sql-error is still there.

from serendipity.

But you know, you are using an unstable - testing Serendipity?!
There you will have more errors shown, than on stable, released = production true systems.
Test it with $serendipity['production'] = true; in serendipity_config_local.inc.php.

That still might happen afterwards, since we even patched the production mode error a little more in 1.7.1, so you might need to upgrade to current master.

from serendipity.

But you know, you are using an unstable - testing Serendipity?!

I think, it is some kind of stable ;)

Test it with $serendipity['production'] = true; in serendipity_config_local.inc.php.

Done, but some error-message as you can see at http://bernd.distler.ws/frontpage/archives/P144.html

from serendipity.

Could you temporarily disable those plugins:

serendipity_event_contactform
serendipity_event_staticpage
serendipity_event_entrypaging

Regards,
Garvin

from serendipity.

What does your Servers error.log say?

from serendipity.

Could you temporarily disable those plugins:...

Done, but same error again.

After that, i disabled "stable archives". Now, if i go to /index.php?/frontpage and then "next page", i am redirected to /frontpage/archives/P2.html instead of P144.html. But P2 is empty (only webblog-layout) and no sql-error anymore -> http://bernd.distler.ws/frontpage/archives/P2.html

from serendipity.

just for ducumentation:
The mentioned error after production true was a white page error with "An internal server error occurred. Please try again later.", which points to have a look into the servers error.log file, like I already said.
I don't think that switching the 'stable archives' option will help here, as there is the entryproperties cache involved... IMO.

from serendipity.

The mentioned error after production true was a white page error with "An internal server error occurred. Please try again later."

The ubernauten already fixed this problem, there was something wrong with mysqld.

there is the entryproperties cache involved

serendipity_event_entryproperties is not installed and database is cleaned of old cached entries a view month ago.

from serendipity.

Yes maybe, but the current state is a misfeed (using /frontpage) without any error on production true systems. Everything ok, in my eyes!

Garvins point 2, could be solved by an htaccess rewrite rule or something, redirecting /frontpage/archives/ to /archives/ (but does not need to).

from serendipity.

I actually think that due to stable archive sorting the Limit gets a negative offset due to the high page number, which is higher than the numbers of entries. I think this option needs a check to make sure that the Page numbe/offset is never negative. Onli, what do you think?

from serendipity.

FYI: I have set back everything on my weblog including plugins and stable archives. So, don't be surprised :)

from serendipity.

@garvinhicking Yes, that would explain it. We could add a check there, but i'd rather find out why that number is that high.

from serendipity.

I haven't had the time for the past few days to properly check into this, but maybe on bauigels installation the amount of entries per page is set to 1 (or a small number), so the number of pages gets much higher than there actually is? Or maybe this /archives/frontpage gets somehow interpreted as a int and converts to a high number? Just thinking out loud, but I'm sure bauigel is willing to add some debug code if we can add some debugging in the calculation formular?`!

from serendipity.

I have 5 entries per page :)

Give me some code and i'll add it.

from serendipity.

Ok. I was able to reproduce the error (though in my 2.0-install, i don't get a sql-error, just no entry printed on page 2). The bug is https://github.com/s9y/Serendipity/blob/master/index.php#L138 - the assumption that the first three arguments are always year, month and date is wrong in that case, and leads here to $year being set to "archives".

My patch would be to insert below that line:

if ($year == "archives") {
    unset($year);
}

Could you please test if it helps in your blog?

I don't want to commit it to 2.0, because I think that part should be rewritten or removed anyway.

from serendipity.

Seems to work for me :)

from serendipity.

Maybe instead of a string comparison, we should unset the values if they are not ^[0-9]$ ? And maybe even apply to year, month and day?

from serendipity.

Maybe. There is a range of code after, does that really always asume that those args are numeric? Why are we in a calendar-based logic anyway if no args containing date are appended to the url?

from serendipity.

I hadn't had the chance to check this, I was just throwing in some comment, sorry if that might already be covered in the later codeflow...

from serendipity.

Please also read, if that isn't also a combination with this (bug) http://board.s9y.org/viewtopic.php?f=3&t=19468
(eg PHP Fatal error: Uncaught exception 'SmartyException' with message 'Unable to load template file '-3' in 'file:/var/www/html/templates/oldbulletproof/entries.tpl''...)

Forget it, please! I mixed things up....

from serendipity.

TL;DR

Is this solved in both branches now? If so, someone please closed the issue.

from serendipity.