one CMS
by Karsten Wade
I'm ready, let's do this.
We need one CMS solution (for sanity sake), although >1 install might be
OK(?), to cover:
* fedoraproject.org
* docs.fedoraproject.org
We need to move some content from the wiki (Licensing/*, Legal/*,
Packaging*) to the CMS.
Why a CMS? Read this:
http://iquaid.org/2008/08/13/why-and-where-fedora-needs-a-cms-solution/
Getting a CMS is a solution to a blocker for upgrading MediaWiki. The
code we use for MW ACLs is not supported in the latest release, and our
version is going out of security update support. By moving all content
out of the wiki that needs ACLs, we don't have to have that code and
upgrading is made possible. That also gets us to where we can use
Nigel's localization setup.
Reportedly we'll get a speed improvement on the wiki without the HNP
code. So sayeth Nigel. See #fedora-admin for details.
CMS must haves
--------------
* Good security record
* Proactive security mindedness of developer community
* Flexible enough auth system to attach to FAS
* RSS
* ...
CMS should haves
----------------
* OpenID
* WYSIWYG editor
* ...
Have at it!
- Karsten
--
Karsten Wade, Sr. Developer Community Mgr.
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41
15 years, 8 months
Re: one CMS
by Mohd Izhar Firdaus Ismail
2008/8/14 Karsten 'quaid' Wade <kwade(a)redhat.com>:
> I'm ready, let's do this.
>
> We need one CMS solution (for sanity sake), although >1 install might be
> OK(?), to cover:
>
> * fedoraproject.org
> * docs.fedoraproject.org
>
> We need to move some content from the wiki (Licensing/*, Legal/*,
> Packaging*) to the CMS.
>
> Why a CMS? Read this:
>
> http://iquaid.org/2008/08/13/why-and-where-fedora-needs-a-cms-solution/
>
> Getting a CMS is a solution to a blocker for upgrading MediaWiki. The
> code we use for MW ACLs is not supported in the latest release, and our
> version is going out of security update support. By moving all content
> out of the wiki that needs ACLs, we don't have to have that code and
> upgrading is made possible. That also gets us to where we can use
> Nigel's localization setup.
>
> Reportedly we'll get a speed improvement on the wiki without the HNP
> code. So sayeth Nigel. See #fedora-admin for details.
I'm biased ... the Python CMS that runs on Zope ... Plone!!! ... :P ..
>
> CMS must haves
> --------------
> * Good security record
checked
> * Proactive security mindedness of developer community
checked
> * Flexible enough auth system to attach to FAS
PloneLDAP
> * RSS
all over the place
> * ...
>
> CMS should haves
> ----------------
> * OpenID
checked
> * WYSIWYG editor
checked - its using Kupu .. also supports lots of markups like ReST,
wiki markups, etc.
> * ...
>
> Have at it!
others:
- contents are stored like inside a filesystem (folders, contents)
- contenttype easily done using argoUML, code generated using archgenxml
- templating using TAL (similar to turbogears's KID) - XML valid,
clean, no need to mess with python
- considering its python, might allow greater integration with
python-fedora libraries, turbogears, and other python libs.
- powerful caching when installed with squid as accellerator combined
with the CacheFu product (CacheFu will invalidate squid cache when
changes occur)
- powerful indexing & searching capability (can index uploaded pdf,
odf, doc, txt, etc)
- and bunch more
Cons:
- require py2.4 ..
- small choice of custom Products (plugins)
- consume quite some RAM
the fedoraunity guys know more i guess ..
>
> - Karsten
> --
> Karsten Wade, Sr. Developer Community Mgr.
> Dev Fu : http://developer.redhatmagazine.com
> Fedora : http://quaid.fedorapeople.org
> gpg key : AD0E0C41
>
> --
> Fedora-websites-list mailing list
> Fedora-websites-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-websites-list
>
>
--
Mohd Izhar Firdaus Bin Ismail
Amano Hikaru
天野晃 「あまの ひかる」
http://fedoraproject.org/wiki/MohdIzharFirdaus
http://blog.kagesenshi.org
92C2 B295 B40B B3DC 6866 5011 5BD2 584A 8A5D 7331
15 years, 8 months
Websites Meetings
by Max Spevack
Hi team,
We're scheduled for a meeting tonight at 22:00 UTC and next monday at
20:00 UTC.
I'm taking my summer vacation starting tonight, and I won't be back
until next Wednesday, so I'll be missing both of these meetings.
Which brings me to a larger topic:
A couple of months ago when Mike McGrath asked someone to start holding
Websites meetings regularly, I volunteered because I wanted to step in
and fill a need. But as you all know, I am not deeply active in the day
to day coding or design that goes on in Fedora Websites. It was always
the objective that once some momentum had been built up, and there were
a number of tasks being worked through, that "leadership" of the
Websites project could transfer to someone in the community who wanted
to step into that role.
Are we ready for that yet? Is anyone feeling inspired?
Here's the critical path, IMHO:
(1) get-fedora into F10 shape, and incorporating a link to (2), below.
(2) spins.fp.o into small, achievable milestones. The first milestone,
IMHO, needs to be a "spin information page" which contains basic
information about the spin, a .ks and a link to torrents, ISOs (wherever
they are hosted), or other download mechanisms. The second milestone is
a basic index of all spins. The third milestone is workflow to automate
the addition and deletion of spins from the index.
(3) Finding, developing, and recruiting people who are interested in web
application development. Making it as SIMPLE AS POSSIBLE for someone to
have a turbogears application, with Fedora look and feel, up and running
on a test instance somewhere in our infrastructure.
(4) Respond to whatever comes up on a weekly basis that needs attention.
That's my little roadmap. What do y'all think?
--Max
15 years, 8 months
CMS eliminators
by Stephen John Smoogen
Sadly, one of the first issues in choosing a CMS will be what
'language' it is written in. I say sadly because this can also be the
first of a long seige war where people who believe that embedded COBOL
is the only way to write a CMS [isn't that what the C stands for] will
bring it up every couple of weeks. In looking at a CMS, are there
going to be certain 'languages' that are off the table from the
beginning? (mod_cobol is probably one).
A year ago, I would have said any CMS written in PHP would have had a
tough slog onto Fedora infrastructure, but with Mediawiki I think that
has been put to rest. But it would probably have to be shown that any
PHP CMS could work with various known to be bad or tough to secure
features turned off.
--
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"
15 years, 8 months
Re: one CMS
by Yannick Lyn Fatt
----- Original Message -----
From: Nigel Jones <dev(a)nigelj.com>
To: "For maintainers and developers of all formal Fedora
websites." <fedora-websites-list(a)redhat.com>
Subject: Re: one CMS
Date: Thu, 14 Aug 2008 12:01:38 +1200
>On Wed, 2008-08-13 at 16:01 -0700, Karsten 'quaid' Wade
>> wrote: I'm ready, let's do this.
>>
>> We need one CMS solution (for sanity sake), although >1
>install might be
>> OK(?), to cover:
>>
>> * fedoraproject.org
>> * docs.fedoraproject.org
>>
>> We need to move some content from the wiki (Licensing/*,
>> Legal/*, Packaging*) to the CMS.
>>
>> Why a CMS? Read this:
>>
>>
>http://iquaid.org/2008/08/13/why-and-where-fedora-needs-a-cms-solution/
>>
>> Getting a CMS is a solution to a blocker for upgrading
>> MediaWiki. The code we use for MW ACLs is not supported
>in the latest release, and our
>> version is going out of security update support. By
>moving all content
>> out of the wiki that needs ACLs, we don't have to have
>> that code and upgrading is made possible. That also gets
>> us to where we can use Nigel's localization setup.
>>
>> Reportedly we'll get a speed improvement on the wiki
>> without the HNP code. So sayeth Nigel. See
>#fedora-admin for details. Okay, heres the run down, in a
>completely unscientific test (although nearly scientific),
>I found that Mediawiki+HNP makes the wiki THREE times
>slower.
>
>Now the problems also are (with the current setup):
>1. HNP does not support Mediawiki > 1.11.2
>2. Per 1. we are locked into Mediawiki 1.11.2
>3. Per 2, we won't have any security updates once Mediawiki
>1.13.x comes out (anytime now)
>4. We are limited in options for l10n content
>5. With the current state of the Mediawiki codebase, it
>could be more desirable (imo) for us to work off SVN
>versions like Wikipedia etc do (they update the wiki every
>couple of days from SVN once it's been proven as working on
>the test wiki). 6. HNP is just slow, and the code is
>> disgusting.
>> CMS must haves
>> --------------
>> * Good security record
>> * Proactive security mindedness of developer community
>> * Flexible enough auth system to attach to FAS
>> * RSS
>> * ...
>>
>> CMS should haves
>> ----------------
>> * OpenID
>> * WYSIWYG editor
>> * ...
>>
>> Have at it!
>
>http://www.opencms.org
>
>That said... http://www.silverstripe.com looks rather
>nifty. Plus they are having a meetup in Auckland not too
>far from me, so if we are interested I'll pop along and say
>hi on behalf of Fedora :)
>
>- Nigel
>
What about Drupal? http://www.drupal.org
- Yannick
15 years, 8 months
Re: Drupal CMS for Fedora
by Yannick Lyn Fatt
----- Original Message -----
From: "Naheem Zaffar" <naheemzaffar(a)gmail.com>
To: fedora-websites-list(a)redhat.com
Subject: Drupal CMS for Fedora
Date: Thu, 14 Aug 2008 15:45:53 +0100
>Hi all,
>
>Just registered with this list after reading Karsten's blog
>on Planet Fedora.
>
>As the title suggests, I would recommend Drupal as a CMS.
>
>It has a modular design, and I expect it would not be too
>much effort to create a module to auth against FAS and
>there are many additional hooks. It has roles/groups based
>permissions which can be added to via additional access
>modules - specify who can view/edit/add what and where -
>all separated via "content type". Version 6.x of Drupal
>also has good internationalisation support from what I
>hear.
>
>RSS comes as standard, as does book/outline ability which
>is similar to the documentation system pages/contents
>currently used.
>
>It has good theming potential where the themes are pretty
>well separated from the content. The main benefit of Drupal
>is the contributed modules, Mainly CCK and Views.
>
>CCK - custom content types, allows you to create custom
>content types with as many/few fields needed - you can
>create a content type that has a predefined number of
>fields/text area's for whatever is needed. This could be
>extremely useful for things such as the feature process.
>
>"Views" can be used to list/display things in various ways
>depending on arguments provided to it. Very powerful.
>
>through the use of pathauto module, you can add url
>namespacing which may be of benefit to some.
>
>Admittedly a lot of the community oriented featured would
>proabably be go unused on the fpo website, but there are
>plenty of others that are very useful.
>
I agree with Naheem and also made the suggestion in the
other thread started on the mailing list regarding a CMS
solution being needed for fp.o.
- Yannick
15 years, 8 months
Drupal CMS for Fedora
by Naheem Zaffar
Hi all,
Just registered with this list after reading Karsten's blog on Planet Fedora.
As the title suggests, I would recommend Drupal as a CMS.
It has a modular design, and I expect it would not be too much effort
to create a module to auth against FAS and there are many additional
hooks. It has roles/groups based permissions which can be added to via
additional access modules - specify who can view/edit/add what and
where - all separated via "content type". Version 6.x of Drupal also
has good internationalisation support from what I hear.
RSS comes as standard, as does book/outline ability which is similar
to the documentation system pages/contents currently used.
It has good theming potential where the themes are pretty well
separated from the content. The main benefit of Drupal is the
contributed modules, Mainly CCK and Views.
CCK - custom content types, allows you to create custom content types
with as many/few fields needed - you can create a content type that
has a predefined number of fields/text area's for whatever is needed.
This could be extremely useful for things such as the feature process.
"Views" can be used to list/display things in various ways depending
on arguments provided to it. Very powerful.
through the use of pathauto module, you can add url namespacing which
may be of benefit to some.
Admittedly a lot of the community oriented featured would proabably be
go unused on the fpo website, but there are plenty of others that are
very useful.
15 years, 8 months
need help
by Sean
I use KDE on a FC7 box.
Every time I try to use Konqueror (the file manager/web browser) it opens
NOT with a blank window, but with <http://start.fedoraproject.org/>.
What I WANT and NEED is a blank window and a blank location bar.
There seems to be no way in the GUI configuration to fix this.
I looked at the konquerorrc file but the answer doesn't seem to be hidden
there.
Advice would be greatly appreciated.
Sean Kilpatrick
kilpatms(a)speakeasy.net
15 years, 8 months
