Long Term / KDE.org Design Update

Ben Cooksley bcooksley at kde.org
Wed Jul 15 05:11:12 UTC 2015


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.

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?

>
> 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


More information about the kde-www mailing list