miwilc

@Bailey you can change it directly in the MW settings, it isn't a far stretch.

Or alteast redirect /$1 to /wiki/$1 (which is what Wikipedia does.)

Avoid directly using the .htaccess it should always be treated as a last resort, since it could break things...

Thanks for the Https.

Edit:

--

@krydos let us know what you think of the license, I still think CC BY is the best.

@Krydos maybe we could use a .htaccess as a last resort?

Also, what do you think of the license? I would recommend the CC BY as I mentioned earlier, I think it would be ideal for heliohost.

The article links are still not right, it should be /$1 not /wiki/$1

Yeah, please try to keep custom code to a minimum as (I assume) we will be keeping wiki up to date because things break; and I like the default theme actually, why do we need a custom one again?

Apart from the logo.png missing it looks to be quite good,

You should probably demote yourself to a verified contributor after the wiki is ready, the admins need to decide on whether somebody can be wiki maintainer(s?) or if the admin team can handle it.

please let us know when your ready to sync to the main domain.

Great job so far

Also: Please enforce/redirect to Https on the test site. Please.

Edit: I don't recommend creating accounts /editing posts on the test wiki, we should wait till it's moved to the main domain.

Edit #2: make sure the title URL is <website>/<title> not <website>/index.php/<title>

This could be important

Edit #3:

I just done a slightly more close look.

It seems that you have decided to use a

CC BY-SA-NC license for the website,

I immensely disagree that we should use that license for our wiki (for obvious reasons).

I recommend the CC BY license (https://creativecommons.org/licenses/by/4.0/) for our website.

@Krydos We can always change our DNS resolver

I recommend Google Public DNS/OpenDNS.

Use Google Public DNS for your DNS resolving, I have the same problem resolving sites with the default provider.

Also @wolstech: The default provider always sucks, IMHO... Try G-Public DNS.

Link: https://support.google.com/accounts/answer/6010255?hl=en

It doesn't require it, just install it your home pc and then upload it.

Can Hugo do basic interactive elements like a contact form? I haven't had time to look into it more...

Hugo (&jekyll) aims to be fully static, so most or all dynamic features are hosted by third parties (implemented via JS), Like https://disqus.com/ for comments.

And according to the discourse: https://discourse.gohugo.io/t/is-it-possible-to-add-a-contact-form-to-a-site/1550/2 https://formkeep.com/ or formspree is recommended for forms (I haven't tried it, but it seems quite simple.)

It says me the page has redirected too many times...

You need to clear your browser cache...

I think it may be time to start writing an article on how to migrate away from wordpress to Hugo/Jekyll as it seems that a few Helio members still use Wordpress when there is usually no need of it...

We should look into having Hugo/Github-jekyll on our production servers at a later point, this could simplify the process a lot (i.e: daily Cron jobs to build the site from the source hosted on the server.)

I just tested the outbound port 587 connection to 173.194.202.108 and 173.194.202.109 from Tommy and they both work. Does it help if you specify the IP directly?

He needs to enable unsecure application logins in his security settings. This is not a problem with heliohost or Google domains.

If your on Tommy, remove all the manual certs and wait for the certs to be auto-issued by the server.

 

Also, @Krydos you should try out solus

You should have said something sooner. I just installed Ubuntu 17 on my new laptop last night.

Then again, if you don't: I would recommend Solus. And a separate /home never hurt anyone... I remember installing over 5 distros on my craptop to test each one. I settled on Solus.

@Bailey 13,400 conf Files? Wtf?

Can't you just replace the files you edited instead of transfering the full thing?

Also: I still think it's easier to work from localhost.

Also Also: compress files and then upload it, you can decompress on the server.

And why do you need a copy of the wiki?

 

I feel your limited by running the wiki on heliohost, you must run it on localhost to make it easier to work on.

(Preferably edit /etc/hosts to point 127.0.0.1 to wiki.helionet.org)

@Bailey upload the compressed updated dB to your home and then @Krydos can import it.

If all this fails, Krydos give a copy of the compressed dB and files (of the current wiki, I need this as well.) on my account and I'll download and configure/edit on my localhost (I run Linux, so it's fine...)

it cant do dynamic content (at least without custom code) but for everything else, it seems like a good alternative.

I mean yeah, but you can always use software like disqus for comments and other third party software to add more functionality.

@Krydos you should put it on bailey's account since he will be doing most of the work.

@wolstech Not really, users don't need to learn any language to get started.

Having workable Html/CSS/js skills help, of course (if you wish to have a custom theme)

And Hugo is extremely flexible, I doubt that even a poweruser will ever need to touch the building code.

Some people may wanna try Jekyll since GitHub is pushing it.

@Bailey that seems good, I assume we create/copy the old pages into the new wiki before pushing this to the main wiki.heliohost.org

User accounts and Wiki page history will be lost if you decide to do it like this, but I think it's a good way to upgrade the wiki.

@wolstech Noted, but we can always take our time with the copying the pages over, the person only needs to install it, do the post-inst stuff and create our user accounts.

That said, bailey can probably do this faster since he has more time

--

Are we to discuss possible maintainer(s?) for the wiki? since going out-of-date after we upgraded should be a security risk

<insert irony>

I don't encourage giving access to anyone, I recommend that one of the members of the existing moderation/admin team undertake this task in their free time.

We will need to arrange the planned downtime for the Wiki as well..

In any case this is my suggested plan:

[1] Take backup of current Wiki (incl. files) [Maybe host a copy of this elsewhere temporarily]

[2] Try to autoupgrade

[3] In the event of failure, remove the files&dB

[4] Install Mediawiki LTS

[5] Copy all existing posts

[6] Recreate user accounts

 

Use Hugo (static site gen.) damnit.

 

(https://gohugo.io)

Sorry but, how this framework will help WordPress speed?

By converting you from wordpress to Hugo?

And, Hugo is a static site generator, not a framework.

Thank god!

Use Hugo (static site gen.) damnit.

(https://gohugo.io)

FWIW, the amount of work needed to upgrade the wiki may actually exceed that of just starting over and copy/pasting the articles in...

That's not a bad idea, actually, we could take raw backups of the pages and then create them manually.

Would I be able to upgrade the wiki for you because I don't mind and I understand that you Admins are busy with other more pressing matters?

Either that or we could just ask Krydos to backup the current wiki, remove it and install the latest mediawiki lts, create our accounts and then we can fill in the deleted pages.