Drupal Help Needed: Website needs to be updated to Drupal 7/8

[Aleix Pol]

On Mon, Apr 25, 2016 at 6:04 PM, Milian Wolff <mail at milianw.de> wrote:
> On Monday, April 25, 2016 4:39:43 PM CEST Kevin Funk wrote:
>> On Monday, April 25, 2016 7:20:01 AM CEST Alexandre Courbot wrote:
>> > On Mon, Apr 25, 2016 at 12:04 AM, Milian Wolff <mail at milianw.de> wrote:
>> > > On Sonntag, 24. April 2016 14:45:14 CEST Alexandre Courbot wrote:
>> > >> On Sun, Feb 28, 2016 at 10:08 AM, Aleix Pol <aleixpol at kde.org> wrote:
>> > >> > On Fri, Feb 26, 2016 at 7:48 PM, Milian Wolff <mail at milianw.de>
> wrote:
>> > >> >> Hey all,
>> > >> >>
>> > >> >> our KDevelop website is still running on Drupal 6 which is now
>> > >> >> officially
>> > >> >> unsupported! We must act _now_ to update the website to Drupal 7.
>> > >> >>
>> > >> >> Is anyone available to help in the effort? Otherwise I'll try to
>> > >> >> tackle
>> > >> >> this task myself. I'd rather spent the time fixing KDevelop of
>> > >> >> course
>> > >> >> ;-) So if someone in our user base has experience in that area -
>> > >> >> please
>> > >> >> step forward!>
>> > >> >
>> > >> > Hi Milian,
>> > >> > Thanks a lot! I wouldn't know where to start from.
>> > >> >
>> > >> > Would it be possible to port it  less customized so we can upgrade
>> > >> > whenever they release? For my blog I use wordpress and I haven't had
>> > >> > issues with upgrades. I understand the needs might be different, but
>> > >> > nowadays our website is little more than news and links to the wikis.
>> > >>
>> > >> Sorry, this is an old thread but since I am in the same situation (old
>> > >> websites running Drupal 6) I thought I might share my experience.
>> > >>
>> > >> Kdevelop.org seems to be mostly (entirely?) a collection of static
>> > >> pages. Have you considered moving to a static page generator? The
>> > >> advantages are numerous:
>> > >>
>> > >> * No need for PHP/MySQL, data is easy-to-read text files
>> > >> * No upgrade stress, no need to apply security fixes on the server
>> > >> beyond Apache/Nginx
>> > >> * Edits are simple & clean, done using Markdown and pushed to a git
>> > >> server
>> > >> * Website is faster and more responsive since the pages don't need to
>> > >> be generated
>> > >>
>> > >> The only drawback I can see is that the data needs to be ported to the
>> > >> static generator. In my case I only have a handful of pages so I just
>> > >> copy/pasted the content's HTML into text files, but in the case of
>> > >> KDevelop you may want to use one of the Drupal converters that exist
>> > >> for most projects (or maybe just write your own).
>> > >>
>> > >> I have chosen to use Hugo (https://gohugo.io/) but there are many
>> > >> others that are probably equally suited to the task.
>> > >>
>> > >> The biggest advantage to the switch is that you don't have to care
>> > >> about the servers anymore. Is my server up-to-date? Will MySQL restart
>> > >> properly after I upgrade? Oh no, I have to do a manual upgrade of
>> > >> Drupal again, including putting the site off-line and running the
>> > >> update scripts... All that is over. Git pull, edit, git push, and a
>> > >> server hook regenerates the pages. Less time spent administrating,
>> > >> more time spent doing actual development.
>> > >
>> > > I thought a lot about this, and I still think about doing this for my
>> > > personal website. And maybe in the long term also for the KDevelop
>> > > website.
>> > >
>> > > The biggest issue I had which refrained me from ditching Drupal
>> > > altogether
>> > > was>
>> > >
>> > > the commenting feature:
>> > >> Dynamic things such as comments can be delegated to Javascript and
>> > >> external entities (like disqus), but it is also possible to host your
>> > >> own comments server.
>> > >
>> > > Disqus is not an option for a KDE website, imo, as they own the content
>> > > and
>> > > place quite some burden on the commenters. The only feasible alternative
>> > > would be a self-hosted one on KDE infrastructure, but then we'd have to
>> > > spent quite some time in migrating the drupal comments to the new
>> > > infrastructure. And looking at the options for self-hosted ones, I found
>> > > no clear answer as to which one to pick. Isso, Hashover, ... none of
>> > > them
>> > > seems to be "really" big and thus guaranteed to be around for long. If
>> > > you have any suggestions as to what to use, we might want to reconsider.
>> >
>> > I don't have any clear suggestion to make here, especially since my
>> > solution to this problem has been to ditch comments altogether (I came
>> > to *hate* web comments for the most part). That's maybe not an option
>> > for KDevelop, although there are many other communication channels
>> > (KDE forums, etc.) that could replace them.
>>
>> Undecided here.
>>
>> I like the comment section since it usually contains a number of interesting
>> comments related to the topic (e.g. on release announcements): People point
>> out problems in the release tarballs, or ask for installers on non-Linux
>> platforms for this particular release. When pointing people to forums and
>> mailing lists the information will be scattered around.
>>
>> Not sure.
>>
>> Something to discuss face-to-face in Randa maybe (/me adds a TODO item)
>>
>> > My intent was to make sure
>> > that you guys were aware of the options that require less maintainance
>> > than a full-blown CMS (or in this case, none at all), since there
>> > seems to be a lack of resources to maintain Drupal.
>>
>> Drupal isn't the problem, IMO. It's a general lack of interest in
>> maintaining and advancing/modernizing the KDevelop website.
>>
>> And I think we'd still like to aggregate & store developer blog entries on
>> kdevelop.org, I don't think that's easily doable with static pages.
>
> True, I forgot about that part. Blog and comment aggregation (both via Atom/
> RSS) is a nice addition to our website. What it helps in conveying is that our
> project is alive and kicking. But embedding a github-style heatmap could work
> as well for that purpose, with a link to phabricator pages for more details...
>
> The developer aggregation could be handled by a separate planet aggregator, if
> needed. But that means additional maintenance there then, esp. for the
> themeing.

I agree, RSS is a must for any direction we should take.

Regarding Planet aggregation, there's already different planets being
aggregated within planetkde.org, maybe we could get our own within
planetkde (hence removing the maintenance burden).

Aleix