Die mehrwelt
CMS
Microsoft hat angekündigt, dass alle Windows Live accounts für OpenID freigeschaltet werden. Damit kann man sich dann mit seinem Windows Live Account (derzeit angeblich rund 420 Millionen Accounts) an OpenID-kompatiblen Websites anmelden.
Auch TYPO3 wird in der kommenden Version 4.3 über eine OpenID Schnittstelle direkt im Core verfügen (eine Erweiterung dazu gibt es schon länger). Die Integration dieser Schnittstelle wird derzeit in der Entwicklungsliste heiß diskutiert.
Seit dem 1. September 2008 stehen alle aktuellen und künftigen Versionen des YAML-Templates (basiert auf dem bekannten CSS-Baukasten YAML) unter der GPL und dürfen kostenlos und ohne Zahlung einer Lizenzgebühr auch komerziell verwendet werden.
Der Entwickler des TYPO3 Templates schreibt:
Warum dieser Schritt?
Abgesehen von den Querelen, die sich mit der Auszahlung der Einnahmen aus den Lizenzverkäufen an mich ergeben haben, habe ich dies schon seit längerer Zeit überlegt und geplant. Die Antwort ist ganz einfach. Ein freies und quelloffenes CMS wie TYPO3 lebt davon, daß soviele Entwickler wie möglich dazu beitragen, daß es besser und leistungsfähiger wird. Lizenzgebühren für ein einzelnes Modul zu verlangen, paßt nicht zum Konzept von TYPO3.
Anders als das TYPO3-Template steht YAML selbst weiterhin unter der Creative Commons Lizenz (CC-A 2.0), also die Attribution Lizenz. Das heisst, für die kostenfreie Nutzung des YAML-Frameworks ist die Rückverlinkung zur YAML-Homepage in der Fußzeile der Website oder im Impressum vorgeschrieben.
Im Google Webmaster Central Blog wird diskutiert, wie man als Webmaster – oder Entwickler – mit dynamischen und statischen URLs umgehen kann (und soll). Ein interessanter Artikel, der an einer Stelle sinngemäß schlicht rät, die URLs um alle unnötigen Parameter zu bereinigen und »doch Google den Rest erledigen zu lassen«. (Aber welcher SEO-Spezialist und Entwickler kann das – bei seiner Ehre – schon…)
Abgesehen davon ist ein Absatz wesentlich:
»Which can Googlebot read better, static or dynamic URLs?
We’ve come across many webmasters who, like our friend, believed that static or static-looking URLs were an advantage for indexing and ranking their sites. This is based on the presumption that search engines have issues with crawling and analyzing URLs that include session IDs or source trackers. However, as a matter of fact, we at Google have made some progress in both areas. While static URLs might have a slight advantage in terms of clickthrough rates because users can easily read the urls, the decision to use database-driven websites does not imply a significant disadvantage in terms of indexing and ranking. Providing search engines with dynamic URLs should be favored over hiding parameters to make them look static.«
Conditional Comments for HTML Email: „
Take a look at this:
<!--[if gte mso 9]>
<![endif]-->Chances are the general syntax will be instantly familiar — it’s a conditional comment, useful for feeding specific content only to Windows versions of Internet Explorer. But did you know they work for Office applications too?
Neither did I … until recently.
We’ve just overhauled the HTML templates for our email newsletters … a painful process to be sure — if you think that web browsers are harsh task-masters, you should try coding to suit email clients! A recent article, How to Code HTML Email Newsletters, spells out just how convoluted it can be, and how arcane are the techniques you have to resort to, to produce a decent layout in the most popular email clients. And the issue has been further complicated by the fact that one of the most popular Windows clients — Outlook — no longer uses Internet Explorer for HTML rendering, it uses Word!
And it was while perusing the franken-code that passes for ‘Save as Web Page’ output from a Word document, that I first saw these little nuggets — exactly what we needed to hide bits of content from Outlook that were just too mangled to leave.
So there you go. If you’re publishing HTML email and struggling with Outlook’s rendering, here’s an extra little tool for the kit. The syntax even implies that it can be used for granular targetting of Office versions all the way back; but I haven’t tested this, so any information is gratefully received :)
(Via SitePoint Blogs.)
Formulare ermöglichen einen direkten Kontakt zu den Besuchern einer Seite und erfragen zum Beispiel Daten für Newsletter, Kommentare und Adressen. Das Design ist schnell erledigt, doch ohne PHP-Kenntnisse wird daraus kein nützliches Formular. Wer gerade keinen PHP-Entwickler zur Hand hat, der kann auf die Web Form Factory zurückgreifen.
Web Form Factory: Open Source Generator für Formulare
Die Erstellung von Formularen für eine Webseite bleibt in aller Regel entsprechend geschulten Entwicklern vorbehalten. Die optische Gestaltung stellt für viele Publisher keine große Hürde dar, bei der Programmierung der Formulare sieht das schon anders aus. Hier sind spezielle Kenntnisse gefragt, um die Formulareingaben in einer Datenbank speichern oder per E-Mail versenden zu können.
Mit der Web Form Factory (WFF) gibt es jetzt eine Open-Source-Lösung zur Erstellung von Formularen für das Web. Die einfach zu bedienende Web-Applikation untersucht eine selbst erstellte HTML-Datei auf verwendete Eingabetypen wie Textfelder, Drop-Down-Listen, Checkboxen sowie Radio-Buttons und generiert daraus automatisch ein an PHP-gebundenes HTML-Formular. Das Ergebnis lässt sich dann in Form einer Zip-Datei herunterladen, auspacken und in die eigene Webseite integrieren.
WFF befindet sich derzeit im Beta-Stadium. Momentan wird nur die Anbindung von HTML-Dateien an PHP (wahlweise 4, 5 oder 5.1) unterstützt, was sich aber in naher Zukunft ändern soll. Außerdem ist die Erstellung eines E-Mail-Formulars möglich, bei dem die erhobenen Daten nicht in eine Datenbank fließen, sondern an eine E-Mail-Adresse geschickt werden.
Eine Hilfestellung für die Arbeit mit WFF inklusive der Erstellung der HTML-Datei bietet ein Einführungsvideo im Tutorial-Bereich.
via t3n
Introduction: 
Chad Auld is one of the principal developers of MiaCMS. MiaCMS is a relatively new open source project, but it’s starting out with a solid base from its roots in Mambo CMS. Chad spent about three years on the Mambo team in various roles including Lead Core Developer and Director on the Mambo Foundation Board; he was a member of the Mambo Steering Committee prior to retiring in February of 2008. Recently, Chad joined with other core Mambo developers to create MiaCMS which is now on its second release. Chad’s role on the MiaCMS team for the first two releases has been to help with the rebranding efforts, build the default WYSIWYG editors, implement the YUI Library, build a REST API for content access, and develop enhanced charting for general CMS statistics and poll results.
How does MiaCMS differentiate itself from other CMS projects out there? Why would someone choose MiaCMS over Drupal or Joomla or other well-known apps in this space?
Yes, there are quite a few content management systems to compete with. Luckily we aren’t really new to the game. Our team contributed toward making Mambo the CMS it is today. We will continue building on that same award-winning base with MiaCMS. (As a side note, it’s worth pointing out that Joomla was also initially based on Mambo about three years ago.)
Some of our current features are:
MiaCMS will differentiate itself by making standard content management operations even easier and more flexible than they have been in the past. We will cleanup much of the old legacy code and enhance the extensions interface to simplify custom 3rd party extension development. With the 4.7 release the team will drop support for PHP4 to take advantage of the object-oriented capabilities of PHP5. The team plans to continue building close ties to the community and listening to their feedback. The next few releases will focus on building out many of the wishlist items we have already received from the community.
At some point, you and the development team made the decision to build YUI into MiaCMS. What were the factors that guided your decision?
We based our decision on a number of important factors; maturity, browser support, documentation, support community, functionality, and flexibility. YUI has a large selection of time-tested components and continues to make valuable additions with each release. For us it is important that the selected framework continue maturing and growing right along side of us. We didn’t want to add yet another library to the system and so it was important to be able to replace existing parts of the CMS with canned components and/or have the flexibility to hook into the framework and use it as a building block for custom components. The YUI documentation is first-class. In fact, it represents some of the best documentation I’ve come across for an open source project. Between the user guides, cheatsheets, api browser, examples, and developer videos, you have just about everything you could ask for. Of course, sometimes documents just aren’t enough. Luckily, we’ve found the YUI support group to be a good place to find additional answers. Last but not least is the topic of browser support. While we’d love to support every browser in existence, it simply isn’t possible. But we do our best to test and code for as many as we can. We think Yahoo! has taken the right approach with its Graded Browser Support model.
What components of YUI are used in Mia?
We are currently utilizing the Reset–Fonts–Grids CSS, Dom Collection, Event Utility, Tabview Control, Button Control, Color Picker Control, Rich Text Editor, Animation Utility, Element Utility, Container Family, and Menu Control. Our production releases also make use of the YUI Compressor which we have integrated with our ANT packager to compress all the CSS and JavaScript in the system. The entire YUI library is included in the system so we are hoping our 3rd party developer community will make use of the library as well. Each custom component comes with its own set of unique requirements and we are confident that YUI can meet their needs, help improve their extensions, and reduce the number of 3rd party libraries the system must carry. In the last release we also build a dynamic loader into the system which allows MiaCMS users to decide between serving files from the local YUI library and serving them from the Yahoo hosting service for the advantages its CDN can bring.
Where do you see opportunities for deeper YUI integration with MiaCMS in the months ahead?
We’ve still got a lot more planned for YUI. Mia is carrying a fair amount of legacy JavaScript code in the system since its Mambo base was started about 7 years ago. We’ll be rewriting a good chunk of the JavaScript in Mia over the next few releases and utilizing YUI where possible. Users can expect a drastic reduction in inline JavaScript. We also plan to move away from older styles of event handling like coding individual onclick/onmouseover events and instead rely on the YUI Event Utility to subscribe to DOM events and help us create custom events with the application. Future releases will make heavy use of the YUI Dom Collection as well as the Event and Selector utilities.
In addition to the custom JavaScript found in the CMS there are also a number of external JavaScript libraries included to handle specific functions like tooltips, menus, calendaring, etc. A goal for the project will be to reduce the number of external dependencies and rely on YUI where possible. Two such replacements have already been almost fully implemented within the CMS core and we have started to encourage our 3rd party developers to make the switch as well with their custom extensions. In past releases the menu system relied on JSCookMenu and all tabs within the system relied on WebFX Tab Pane. JSCookMenu has now been fully replaced with the YUI Menu Control and the WebFX Tab Pane conversion to YUI TabView is about 98% complete. We are currently in the process of replacing overLib tooltips with the YUI Tooltip Control. We will also soon replace ‘The DHTML Calendar’ with the YUI Calendar Control. It would also be pretty safe to say you’ll eventually find ContextMenus, TreeView, DataSource, DataTable, Connection Manager, and JSON being used within MiaCMS. We recently selected Open Flash Charts, but as the YUI Charts Control matures and evolves out of an experimental state that may also find it’s way into Mia.
Having developed a complex application implementing YUI, what are your thoughts on the state of YUI as a toolkit? What’s working super well at this point? What weaknesses are you hoping the YUI team will address?
YUI is a feature-rich, well designed, state of the art toolkit. The available components cover a wide variety of the common tasks needed for web application development. We have had great success integrating YUI deeply into the MiaCMS core which we will continue to do with each passing release. The community feedback on the YUI-related changes has been very positive so far. Support for the major browsers is top-notch, the components degrade nicely, and performance is solid. Tools like the YUI Compressor and YSlow are also key in helping us take performance to the next level.
Nothing much to complain about. Overall we have been very happy with our selection of the YUI Library. One of the things I really like about jQuery is the powerful CSS style selectors. I am really looking forward to the YUI Selector Utility coming out of beta. We’ll probably start making heavy use of it even before then, but obviously the more stable it is the better. I also see a lot of potential for the experimental Charts component so I’d like to see it polished up with its functionality being continually expanded as well.
What are the next big frontiers for the MiaCMS project as a whole?
Below is the list of roadmap items in no particular order. Some are already being worked on, some are almost complete, and others are in the planning stages.
(Via Yahoo! User Interface Blog.)
Dynamic Caching in TYPO3: „When we build social networking sites, we often run into cache-related issues. Read on for a discussion of how to use authentication services to accomplish more dynamic page caching in TYPO3.“
(Via buzz.typo3.org.)
YUI 2.5.2 Released: Bug Fixes and Support for Upcoming Firefox and Opera Releases: „
The YUI development team released version 2.5.2 today; you can download the new release from SourceForge or configure your implementation using the YUI Configurator. This is a focused release that addresses several key bugs while providing support for Firefox 3 and Opera 9.5, both of which are expected to reach GA this summer. Key points for YUI 2.5.2:
After you’ve downloaded YUI 2.5.2 (or changed your pathnames using Yahoo!’s free edge-hosting service), head over to the YUI Community Forum and let us know how it’s working for you.
TYPO3 Association releases Version 4.2: Focus on Usability and Performance Improvements: „BAAR – The TYPO3 Association 4.x Development Team has released a new version of their very successful open source project. TYPO3 has been downloaded over 3.000.000 times from Sourceforge.org which…“
PHP 5.3 bis zu 30 Prozent schneller: „Die Entwickler der freien Scriptsprache PHP haben begonnen, PHP von einem veralteten, Flex-basierten Lexer auf re2c umzustellen. Die aktuelle Entwicklerversion von PHP 5.3 wird dadurch um bis zu 30 Prozent schneller. (PHP, WordPress)“
Erst Benchmarks der aktuellen Entwicklerversion von PHP 5.3 mit PHP 5.2, die Dmitry Stogov veröffentlichte, sehen vielversprechend aus: Demnach ist PHP 5.3 bis zu 30 Prozent schneller als sein Vorgänger. Gemessen wurden die PHP-Applikationen Drupal (20 Prozent schneller), Qdig (2 Prozent schneller), Typo3 (30 Prozent schneller), WordPress (15 Prozent schneller) und Xoops (10 Prozent schneller).
(Via Golem.de.)