Tendenci Templating – we can Improve

Tendenci 4 used basic Dreamweaver DWT files so designers could see everything they were doing. Then we used very strongly typed and very exact html comments along with Python to chop up the template to integrate it with the code.

The benefits were huge in that designers could design, programmers could program. Life was good. Well, almost, there was the whole 2002 use of tables because Netscape and IE were fighting and munged up generated HTMl inside of the script blocks rendered out. Very non MVC but it worked. And it allowed for amazing designer freedom.

Django – Tendenci has been a team effort since 2001 and the big jump came in 2009 when we started the rewrite in fully open source code (old news, I won’t bore you with it, but you can google it.). Django, a web framework written in Python, replaces the custom written framework we built in Tendenci 4 from scratch (hint – avoid writing frameworks from scratch. It makes no sense anymore. Time changes things.)

The problem? Django templates are out of date, they use too much magic (how many times does a designer add a code block and forget the templatetag? Or more common, remove a code block and leave the templatetag out of forgetfulness or fear.

And the worst part – you CAN’T SEE IT unless it is rendered. No more Dreamweaver or any other wysiwyg tools. We take visual people and thrown them into a text based world. For comparison, this would be like coding in Python in Photoshop. It doesn’t make sense.

I wish this post had a happy ending. It is a happy goal. A worthy goal. But the state of affairs with Django and Templates remains stagnant at best as explained here:


We can improve and the future will be brighter when we can just drop in a bootstrap-theme.css file and change our sites as easily as css zengarden.

Nerd Alert: Get your CSS menus in front of the new YouTube player

In an effort to keep up with HTML5, just like Vimeo, YouTube has started to implement <iframe>s for their <embed> codes as a means of displaying their videos. By doing so, it allows a wider variety of devices to view an embedded YouTube (or Vimeo) video.

However, for all you developers out there, this means the old-school way of fixing a CSS-only drop-down menu from going behind an embed code no longer works. Previously (and this still works with the old code), you had to use z-index and wmode=”transparent” to make sure your menus show in front of the video.

The Previous Way

Old embed code:

<object width="640" height="390"><param name="movie" value="https://www.youtube.com/v/fDX7tevXO1E?fs=1&amp;hl=en_US&amp;rel=0"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><param wmode="transparent"></param><embed src="https://www.youtube.com/v/fDX7tevXO1E?fs=1&amp;hl=en_US&amp;rel=0" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" wmode="transparent" width="640" height="390"></embed></object>

Emphasis added. What is in red above was necessary to put CSS menu drop-downs in front of the YouTube player.

The New Way

To get your videos behind the menu as they’re meant to be, the “wmode” is now part of the query string added to the end of the source of the YouTube video:

<iframe title="YouTube video player" width="640" height="390" src="https://www.youtube.com/embed/fDX7tevXO1E?wmode=transparent" frameborder="0" allowfullscreen></iframe>

This will fix your issue.

It should also be noted that, so far, this has only been noticed in Chrome and IE. Firefox appears to behave as normal.