Skip to main content ↑ ↓
Topic: Bug after run from install_php (Read 8468 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Bug after run from install_php

Hello all ;D

I have found a bug!? I not know, that is a bug or not, but I have no Idea how I can install the boardscript. OK, I have the version from github, the last commit is 26 minutes young .. lol

Ok here the message, when I run the install.php in the browser

QuoteA critical error has occurred.

This installer was unable to find the installer's language file or files. They should be found under:
/Elkarte/install/themes/default/languages

In some cases, FTP clients do not properly upload files with this many folders. Please double check to make sure you have uploaded all the files in the distribution.

If that doesn't help, please make sure this install.php file is in the same place as the themes folder.

If you continue to get this error message, feel free to look to us for support.

I hope that can help for the search the bug .. sorry for my englisch, my native lanuguage is german ;D

Greetings

Gerriet
Greetings

Gerriet

Re: Bug after run from install_php

Reply #1 –

Hi Gerriet,
welcome on board :)

The installation is quite simple. Just copy these files from the /install folder to the root forum Folder and run install.php via browser:
install.php, install_1-0_mysql.sql, Settings.php and Settings_bak.php
Alternatively you can install Beta 1, that package was prepared for direct Installation:
https://github.com/elkarte/Elkarte/releases
Last Edit: January 10, 2014, 03:51:17 am by TE
Thorsten "TE" Eurich
------------------------

Re: Bug after run from install_php

Reply #2 –

 emanuele will start again consider the possibility to install from /install instead of from the root... heck it would even be easier to prepare the release! O:-)

And welcome @Gerriet!
Bugs creator.
Features destroyer.
Template killer.

Re: Bug after run from install_php

Reply #3 –

Hello ;D

Thanks you guys for the warm welcome ;D

Greetings

Gerriet
Greetings

Gerriet

Re: Bug after run from install_php

Reply #4 –

And I still have a PR to submit that will fix some of the issues with install and update.  I broke a few things (kind of expected) when I was removing the excess globals from those two files  O:-) I'll get a PR out to fix those this AM!

Re: Bug after run from install_php

Reply #5 –

Ohh... now I remember why I was not testing the upgrade, because I was waiting for your PR!! :P
Bugs creator.
Features destroyer.
Template killer.

Re: Bug after run from install_php

Reply #6 –

what is PR ?
Greetings

Gerriet

Re: Bug after run from install_php

Reply #7 –

Quote from: Gerriet – what is PR ?
PR = Pull request -> this is basically a collection of fixes (or features) sent to our repository.
Thorsten "TE" Eurich
------------------------

Re: Bug after run from install_php

Reply #8 –

While I'm adding in a couple of quick changes ... Minimum db versions, right now we check for a minimum versions:

MySql '4.1.13' released (2005-07-15)
Postgre '8.0',  released January 2005

Release date aside, neither of these are being supported any longer, so why should we say we do?

The current oldest supported version of PostgreSQL is 8.4, until July of this year.  8.4 is also the end of the line for the 8.x series, so after July only 9.x will be officially supported.  I'm not sure what versions of it ship with some of the *nix distro's so we could be conservative here and just change it to 8.1 (released November 2005), but I'd actually vote for 9.0 (September 2010) really due to the low usage rate on this schema anyway, or at least 8.3 which supports full text search.

Now MySql ... I'd say 5.5:P but have seen some data to indicate that 5.0 installs are still common, even though development on 5.0 has ended.  So lets assume 5.0, we can pick the first early stable release, looks like thats 5.0.1 ... or go a bit farther out to 5.0.19 (2006-03-04) which is the first stable release of 5.x in 2006 (so just like 8 years old) and covers most of the incompatible changes.  Frankly we can leave it at 4.1.13 since we don't make use of any 5.0 features BUT changing that helps ensure that going forward we can rely on having 5.x features should we want to use them.

Other thoughts and ideas on this?  If someone says don't change it I'll  :'(

I'm currently thinking which is still pretty conservative IMO, going 5.5 / 9.0 might make even more sense but may limit some installs, then again, that would give us the most opportunity to use newer features.
MySql 5.0.19 or a 5.5.1
Postgre 8.3 or a 9.0

Re: Bug after run from install_php

Reply #9 –

Quote from: Spuds – The current oldest supported version of PostgreSQL is 8.4, until July of this year.  8.4 is also the end of the line for the 8.x series, so after July only 9.x will be officially supported.  I'm not sure what versions of it ship with some of the *nix distro's so we could be conservative here and just change it to 8.1 (released November 2005), but I'd actually vote for 9.0 (September 2010) really due to the low usage rate on this schema anyway, or at least 8.3 which supports full text search.
CentOS (that I heard is quite used around) ships PSQL 8.1 with the 5.x version and 8.4 with the 6.x.

Quote from: Spuds – Now MySql ... I'd say 5.5:P but have seen some data to indicate that 5.0 installs are still common, even though development on 5.0 has ended.  So lets assume 5.0, we can pick the first early stable release, looks like thats 5.0.1 ... or go a bit farther out to 5.0.19 (2006-03-04) which is the first stable release of 5.x in 2006 (so just like 8 years old) and covers most of the incompatible changes.  Frankly we can leave it at 4.1.13 since we don't make use of any 5.0 features BUT changing that helps ensure that going forward we can rely on having 5.x features should we want to use them.
I seem to remember a certain discussion that the code can detect only the version of the client (but I may be badly wrong), either way, I'm on 5.1 and almost no way to change it (unless I'd change hosting... TBH it's thing that I was considering LOL)

Quote from: Spuds – Other thoughts and ideas on this?  If someone says don't change it I'll  :'(

I'm currently thinking which is still pretty conservative IMO, going 5.5 / 9.0 might make even more sense but may limit some installs, then again, that would give us the most opportunity to use newer features.
MySql 5.0.19 or a 5.5.1
Postgre 8.3 or a 9.0
 emanuele can't make Spuds :'(, so I say change it! 5.0/5.1 and 8.4 are fine with me[1]
1 On PSQL there is the issue that from 8.x to 9.x they stopped supporting by default the \' escaping, I'm still not sure is this affects us or not... I think not, but I'm not 100% sure.↵
Bugs creator.
Features destroyer.
Template killer.

Re: Bug after run from install_php

Reply #10 –

My CentOS server has PGSQL version 8.4.18. Id say we stick with ema's suggestion at least until 1.1.
Success is not the result of spontaneous combustion, you must set yourself on fire!

Re: Bug after run from install_php

Reply #11 –

I knew I was forgetting something: travis supports 9.1, 9.2, 9.3, so anyway we are actively testing the 9.x line and not the 8.x:
http://about.travis-ci.org/blog/2013-11-29-postgresql-92-93-now-available/
Bugs creator.
Features destroyer.
Template killer.

Re: Bug after run from install_php

Reply #12 –

QuoteCentOS (that I heard is quite used around) ships PSQL 8.1 with the 5.x version and 8.4 with the 6.x.
I read that as well, not sure what happens when you do an yum on 5.x or what version is in the update package.  Aside from being lazy which I do appreciate, I don't think anyone is stuck on 8.1 so seems safe for 8.3

So what I did on the upgrade/install scripts was use 8.3 and 5.0.19 ... Slightly more modern, gives us fulltext on postgre (something for 1.1 to implement unless someone wants to take a shot at that), and 5.0.19 mostly to set a 2006 release date and to get past most of the 5.0 early churn.  If we find some massive need for earlier versions we can change that back.

Again we don't really need these things, but out of the gate it would be nice to drop some, just a little, baggage.

Re: Bug after run from install_php

Reply #13 –

Drop support for old SQL and php versions. Even if you don't use new features, at least you save yourselves the hassle of supporting bad hosts. Waste of time I say. It's the host's job to ensure their software is up to date.
Wedge requires mysql 5.0 or 5.1, not sure, so we can safely use subselects for instance. Php is 5.3, it's more gutsy because it leaves aside about 30% of servers. But again -- bad servers. They should be encouraged to upgrade. If they don't, things don't improve. Pirates have an easier life. Etc.
Seriously, do yourselves a favor. You don't want to become a new SMF. You have a chance to start from fresh. Do you see yourselves supporting mysql 4 in two years time?

Re: Bug after run from install_php

Reply #14 –

Quote from: Nao – Seriously, do yourselves a favor. You don't want to become a new SMF.
The world changed a lot in the last 10 years... Seriously, not joking.
10 years ago it was all the world about "support everything possible and even something impossible" (even 6 years ago), it was something to be proud of to be able to work on totally outdated software (and hardware). Today... today it's more about being future-proof. And obviously this is nice.

More on the specific case, I think that speak about "supported" is a bit misleading, it is more a "minimum version required". Yes, just semantics, but it changes things: we are not "supporting" php 5.1, Elk requires at least php 5.1 to run, if you have a previous version then you can't run it. If tomorrow Elk will require a higher version, well, that's another story. O:-)
Bugs creator.
Features destroyer.
Template killer.