Long Term / KDE.org Design Update

Albert Astals Cid aacid at kde.org
Wed Jul 15 22:07:40 UTC 2015


El Dimecres, 15 de juliol de 2015, a les 17:11:12, Ben Cooksley va escriure:
> On Wed, Jul 15, 2015 at 5:25 AM, Albert Astals Cid <aacid at kde.org> wrote:
> > El Dimarts, 14 de juliol de 2015, a les 09:35:10, Ken Vermette va 
escriure:
> >> Between Drupal and Wordpress, Wordpress is in a hilariously awkward spot
> >> for me; tooting my own horn I used to make Wordpress do crazy things, and
> >> I
> >> know how to code that platform to do impressive stuff. For example, I
> >> know
> >> I could make a pretty good custom post type which could handle
> >> application
> >> entries easily. I also know how to make it look beautiful.
> >> 
> >> On the other hand, I *hate* Wordpress with a passion. Partially because
> >> of
> >> it's security track-record, mainly because it encourages some bad design.
> >> Apparently they've put effort into the security of the thing, but plugins
> >> are the big area where security falters as well. I'd almost be content to
> >> limit the third-party plugins for security reasons, using only a few
> >> in-house plugins to provide custom page/post types.
> >> 
> >> I don't know Drupal, but from what I understand you can make it do
> >> equally
> >> impressive backflips - but I don't know a lick of Drupal. I don't mind
> >> studying it adding the thing to my resume, but I can't vouch that the
> >> first
> >> run of plugins will be optimal.
> >> 
> >> There's a few things I think we really need to consider, and perhaps we
> >> should make a checklist of things we need, and go CMS to CMS and see
> >> which
> >> ones offer the best faculties - here's what's on my docket;
> >> 
> >>    - Easily extend the system with custom types for app entries, release
> >>    announcements, general news, etc etc.
> >>    - Good administrative options with permissions; we should be able to
> >>    easily grant people permission to make changes in specific areas.
> >>    - Good multi-language support, and an easy method for i18n teams to
> >>    submit translations.
> >>    - Good security track-record. If half the web team dies in a tragic
> >>    beer-pong accident we need to know the site won't crumble.
> >>    - Easy paths to integrate other systems; specifically phpBB and
> >>    KIdentity. I think KIdentity integration will be important.
> >>    - Support for AJAX APIs or a straightforward way to hack em' in,
> >>    ideally
> >>    continuing the KIdentity support.
> >>    - Support reasonably good coding conventions.
> >> 
> >> Thoughts? More points?
> > 
> > You're thinking all this from a web programmer point of view, from my KDE
> > 
> > point of view:
> >  * I like that i can make the announcements from svn since i copy the
> >  file, do> 
> > some replacements and i'm set, i could even script it if i wanted (AFAIK
> > David has some scripts for KF5 announcemnts), no need to fire up a
> > browser, remember some extra user/pass i may have forgotten (this is
> > eased if we get identity.k.o integration), etc.
> 
> Note that this will severely curtail our ability to find people
> willing to generate and maintain content for a website.
> The sort of people interested in working on this tend to be
> non-technical types for whom Subversion is hard, and Git is
> impossible.

I'm not saying commiting files *has to be* the only option, but for those 
doing the work of doing releases now (at least me), it is a much better 
workflow if we *can* use it.

> 
> In any event, i'd like something that imposes uniformity to the
> content (Markdown, Jekyll templating, etc) so we can play with styles
> more easily in the future rather than having CSS hacks everywhere....
> 
> >  * Our translations teams work on .po files they get automatically updated
> >  to> 
> > svn together with all the rest of software translations, they commit the
> > updated .po file and stuff magically happens. Making them learn a
> > different
> > interface for translating just the web is probably not going fly (yes this
> > is the same problem with the wikis, i've been saying this is not good for
> > a long time)
> 
> As in you want the Wikis to flex to how the translators work, or something
> else?

Yes, it's better having a single workflow than 30.

Cheers,
  Albert

> > I'd like those properties to be kept in any possible change for kde.org
> > 
> > Cheers,
> > 
> >   Albert
> 
> Regards,
> Ben
> 
> >> On Mon, Jul 13, 2015 at 11:47 AM, Bart Otten <bart.otten85 at gmail.com> 
wrote:
> >> > And is considered the most vulnerable CMS of all times....Only if we
> >> > render static pages of it's output it's a viable option imho.
> >> > 
> >> > _______________________________________________
> >> > kde-www mailing list
> >> > kde-www at kde.org
> >> > https://mail.kde.org/mailman/listinfo/kde-www
> > 
> > _______________________________________________
> > kde-www mailing list
> > kde-www at kde.org
> > https://mail.kde.org/mailman/listinfo/kde-www
> 
> _______________________________________________
> kde-www mailing list
> kde-www at kde.org
> https://mail.kde.org/mailman/listinfo/kde-www



More information about the kde-www mailing list