Serendipity Forums

on e.g.

http://www.modlog.de/plugin/tag/der+merkel+des+tages

you see how each articles left margin is getting bigger and bigger as you scroll down. Any idea why this might happen?

You are missing a </div> for serendipity_Entry_Date

To figure out exactly what is going on you can download the web developer tools extension for firefox. Once installed you can go to outline -> current element. This will highlight whatever the mouse is hovering over on a web site. Its fixed many problems for me.

Thanks,

but actually I'm not using my own entries.tpl.

In the Theme I'm using there's only a index.tpl. And as far as I understand seredipity templating, in this cases s9y does use the entries.tpl from the "default" template.

On the other hand in the ./temapltes/default/ folders entries.tpl everything seems pretty unchanged compared to the svn version 1.3-alpha1 etries.tpl (at least I haven't changed that.

So where does that result from?

regards
Michael

Hi!

which freetag plugin ver. are you using?

Regards,
Garvin

Hi Garv if freetag is waht shows it self as "Freie Artikel Tags" in German, this one shows 2.92 as its version.

Hi!

Hm, really strange.

Sadly it's hard to debug because your pages contains awful many errors. Can you maybe fix those, so that only the actual error remains?

You must fix many of your entities, you can never use "&" in XHTML, it always needs to be "&" - also in link references. Also, it's never "<br>" but always "<br />".

Then we can check out why the div is intending.

Regards,
Garvin

This div is not closed some or all of the time: Garvin - I have not paid much attention fo the default tpl's for awhile now, but is it intentional that the page footer has the class of .serendipity_entryFooter????

That's a legacy from the original default template I believe, and it should be page footer instead.

[quote="Don Chambers"]This div is not closed some or all of the time: Thanks Don. You pointed directly into the root cause of the problem. Deactivating the Y!Q-Plugin realy repairs the problem mentioned first hand. I'm looking if I can repair that Y!Q stuf myself and will leave it deactivated until then.

Thanks and kind regards
Michael

@Garv

Garv I'm realy not aware of writing any of the br s and & stuf myself, but leave all of this to the various formating plugings. but actually today added the "corect commen xhtml" problems plugin to be sure.

@ Carl - I suspected it was legacy, but I wonder how much of a problem it could be to change it to serendipity_pageFooter, which is what many of your templates, and the bulletproof template, use. I'll let Garvin decide... I don't just want to make a unilateral change to svn on this one.

@ Michael - glad it worked. I was not sure if you were using a plugin for that, or if it was code you were adding manually to your entries. It should be very simple to fix. Also looks like that change, plus any others you have done, have dramatically reduced your errors. You still have a ton more to fix, but it looks like you are moving in the right direction.

Don, the stupid thing is that I mentioned it 18 months ago and thought it had been fixed but I moved on from that template so long ago I don't even know what's in it anymore, I mean tables, ugh, lol. I guess updating SVN without Garvin's permission would be silly, he might have reasons we're not aware of, but...

but honestly, why we still have bugs like this rearing their ugly heads after all this time is beyond me. I personally can't see any valid reason for keeping the status quo, I mean new users won't even know it was a problem, and we don't need to support legacy users since they're unlikely to upgrade their version of Serendipity without also upgrading the template anyway.

This is not so much of a bug as it is a way to provide rules for the page footer differently from the entry footer. Could have been that the original intent was that they look the same, the exception being that it currently has the page footer centered via an inline style.

When I was working on the bulletproof admin, I ultimately revised countless dozens of s9y's core files, including the vast majority of plugins.... Garvin's priority was always to preserve backwards compatibility while simultaneously allowing me to offer new styling opportunities. This is how I was ultimately able to pull off the bulletproof backend while the default backend still works as it did before, even though the 2 are vastly different in appearance from one another.

In this case, replacing the page footer class of serendipity_entryFooter with serendipity_pageFooter would create a problem for any template that defines rules for the first, but not the second.... they would fall out to the parent level, in this case, #content. The solution (if you really want to call it a solution) would be to add serendipity_pageFooter so that both classes exist. That would preserve templates that use entryFooter and allow future templates to style pageFooter differently (if desired) provided those rules occured after entryFooter rules in the stylesheet (or were marked !important). Either of us COULD make this change, but I would rather Garvin weigh in/decide what to do in this instance.

There is no way to change the default to a tableless html structure. Way too many templates have css with table, tbody, td and td. Maybe some day there will be an s9y update whose sole purpose is to eliminate all table structures regardless of what that does to existing templates. I get the feeling that day is not right around the corner due to the monumental effort requried to get there.... especially with respect to the backend and all the plugins.

My opinion on maintaining backwards compatibility in public has always been to maintain the status quo, but in private I have argued that users who need to make use of older tables based templates either won't upgrade, or if they do, they should be given the opportunity within the upgrade screen to use the older tables based template, but in the absence of this, Serendipity should use a new default template that is css only.

I have offered to upgrade all bundled templates to css only if the new default template was also upgraded, so the only problem should be users with custom templates, but honestly, if they want an updated Serendipity then they need to work on their template anyway, and they could even send the darned zipfile to me and I can update it for them myself as I have already done for about 100 users. It's not hard, it's not rocket science, it just requires a commitment to move forward.

I too believe that the default template should get rid of tables. My original designs were based on the stock template and therefore my site used tables. At the time I had no idea that one could create a fully CSS based template. I actually didn't know I could create a template easily with CSS until I finally took a look at bulletproof. It was actually easier to work with bulletproof than the stock template.

At the same time I think that backwards computability is important. It is nice that people can upgrade to the latest version without needing to do a redesign at the same time. I know many people who just will not upgrade if it requires any real work. They would rather stick with what currently works. As someone who cares about security this scares me.

Overall I think that pushing everyone to a pure CSS design is the way to go, but we can't just break people's sites. I have no idea about how much work it would be, but we could make a checkbox during the upgrade process to keep compatibility. As people see this they will realize that their template is old and should be upgraded.

Hi!

Bulletproof is going to become default in s9y 1.3, so the discussions about a non-tableless default template is already decided

Regards,
Garvin