search

auge8472 / My-Little-Forum-1

My Little Forum 1 is a thread based forum with additional board and nested views
GNU General Public License v2.0
6 stars 2 forks source link

First tests #72

Open Helmut01 opened 4 years ago

Helmut01 commented 4 years ago

Hi Auge, my environment on Windows 7 Pro 64bit: XAMP (PHP 7.3.3), Firefox 70.0.01 Tried to play the newbie. Calling install.php() and after submitting: Specified database doesn't exist - please check database name (MySQL: Unknown database 'd00003000') Sure. I suggest to point out in INSTALL that the DB has to be created before. Trap: If the ISP creates it, I don’t think it will be encoded utf8mb4_unicode_ci (what I did). Installed the forum in English.

Cosmetics:

Issues:

Question:

Congratulations: I could post 4-bit UTF8!

Cheers, Alfie

bttrx commented 4 years ago

Hi Alfie!

Regarding ::1: I think, this is your computer's IP address. You said you run mlf on XAMP on your local computer. ::1 represents localhost in IPv6. It's the "same" as 127.0.0.1 for IPv4.

Cheers, Robert

Helmut01 commented 4 years ago

Hi Robert,

You are right! One mystery resolved.

Cheers, Helmut

auge8472 commented 4 years ago

Tried to play the newbie. Calling install.php() and after submitting: Specified database doesn't exist - please check database name (MySQL: Unknown database 'd00003000') Sure. I suggest to point out in INSTALL that the DB has to be created before.

Hmm, there is a checkbox to create the database on the page, where you input the data for the database connection and a query to create the database.

Trap: If the ISP creates it, I don’t think it will be encoded utf8mb4_unicode_ci (what I did).

That shouldn't be a problem. On the one hand it should be good enough when the tables and columns get the correct charset and on the other hand (at least in Germany) the hosters nowadays do create the databases with the charset utf8mb4.

* Version should be 1.8.beta3 (currently beta2)

Damn!

* Advanced settings > quote_symbol was “»”

That looks like the settings page gets delivered by the web server with another charset than UTF-8 (seems to be ISO-8859-1(5?)).

* Right to the text area, the smilies are not centered in the buttons but extend the right margin (i.e., are partly _outside_ of the buttons).

Yes, but the not uniform size of the smilies in the "additional silies" page was a problem since ever. Now I set buttons with fixed size (was links before) and that does not work well for every smiley because some are of different sizes. I don' know, how to handle that but with utf8mb4 we have the possibility to use emojis. In that case we only need a transfer from smiliey-codes to emojis or we need only the renderer (for output) but not the buttons (for input).

* The date-format is `d.m.Y`. Fine for `en-uk`, but confusing for `en-us`.
  Example: 11.09.2001 will be correctly interpreted by a UK reader like the German date but understood by a US reader as November 9th. I suggest the ISO-format `Y-m-d`.

Where do you want to change the date format? Do you mean the language file? Maybe we need a separation of British English and American English? 

* Mix view given as option in the forum settings but not accessible (in Thread view only link to Board view and vice versa).

I can't reproduce the issue. :-/

* In the User profile only Thread and Board views to select.

Looks like the mix view is not really activated. Please look into the settings table and look for doubled entries.

Congratulations: I could post 4-bit UTF8!

:-)

Helmut01 commented 4 years ago

Hi Auge,

Hmm, there is a checkbox to create the database on the page, where you input the data for the database connection and a query to create the database.

Correct. Playing the ‘newbie’ I followed the text which states “For experts”

Trap: If the ISP creates it, I don’t think it will be encoded utf8mb4_unicode_ci (what I did).

That shouldn't be a problem. On the one hand it should be good enough when the tables and columns get the correct charset and on the other hand (at least in Germany) the hosters nowadays do create the databases with the charset utf8mb4.

Hopefully. ;-)

  • Advanced settings > quote_symbol was “»”

That looks like the settings page gets delivered by the web server with another charset than UTF-8 (seems to be ISO-8859-1(5?)).

Don’t think so. My Apache’s default is UTF-8; checked the database and the header of the HTML.

I made a fresh install. Same, strange. In install.php $settings['quote_symbol'] = "»"; and the file is encoded UTF-8. BTW, there are some files encoded in ANSI. Please check.

Another story: When I reply to a post, I see the Category: select-box but it is empty (in my forum the category is shown but cannot be changed). Should we hide it instead? Not sure.

Yes, but the not uniform size of the smilies …

OK, not a problem.

… but with utf8mb4 we have the possibility to use emojis. In that case we only need a transfer from smiliey-codes to emojis or we need only the renderer (for output) but not the buttons (for input).

I would be cautious with 4-btye UTF-8 (I have even a warning in the Instructions of my forum). If the UTF-8 codepoint is not contained in the fonts suggested in the CSS, well… Most browsers go those fonts (here: verdana, arial, sans-serif) and try all fonts installed on the machine. At least on Windows the highest support is in “Segui UI” and “Segui UI Symbol”. If not contained, bad luck. BTW, I would add “helvetica” after arial to the CSS. AFAIK, it is the standard on OSX.

The date-format is d.m.Y. Fine for en-uk, but confusing for en-us.

Where do you want to change the date format? Do you mean the language file? Maybe we need a separation of British English and American English?

Yes and no. Of course the admin could change the date format in the language file. Two english files – don’t think that it is necessary. Currently english.php() – apart from the “German” date format uses American English in one word only (en-us: authorization, en-uk: authorisation). I still think that the ISO-format should be preferred in all files.

Mix view given as option in the forum settings but not accessible (in Thread view only link to Board view and vice versa).

I can't reproduce the issue. :-/

My not either. Sorry, forget to set it.

An old story: When I’m logged in (mix view) and log out, I end up in thread view. However, when I’m in board view, I end up in the mix view (set as the default in the installation).

Question: In _userdata user_name is utf8mb4_unicode_ci varchar(64). OK, makes sense. But why in _entries name is utf8mb4_unicode_bin varchar(64) and edited_by is utf8mb4_unicode_ci varchar(255)?

Cosmetics: Since the content is delivered as HTML5, you can drop the / in same tags (br, closing img).

auge8472 commented 4 years ago

Hello Alfie

Hmm, there is a checkbox to create the database on the page, where you input the data for the database connection and a query to create the database.

Correct. Playing the ‘newbie’ I followed the text which states “For experts”

I'll look into it to make things more clear. If you (or someone else) have (has) ideas, I'm open for proposals.

  • Advanced settings > quote_symbol was “»”

That looks like the settings page gets delivered by the web server with another charset than UTF-8 (seems to be ISO-8859-1(5?)).

Don’t think so. My Apache’s default is UTF-8; checked the database and the header of the HTML.

I made a fresh install. Same, strange. In install.php $settings['quote_symbol'] = "»"; and the file is encoded UTF-8.

Hmm ...

BTW, there are some files encoded in ANSI. Please check.

Oh, I thought to have changed all script files. Do you have a list of affected files oy found?

Another story: When I reply to a post, I see the Category: select-box but it is empty

O.k., I'll have a look.

(in my forum the category is shown but cannot be changed).

That's how it should work.

Should we hide it instead? Not sure.

No, the user should see the category name. But as it's not editable, it can be shown in a text element, i.e. in p or in a theme for modern browsers in output.

Yes, but the not uniform size of the smilies …

OK, not a problem.

It's a problem, even a cosmetic one. It doesn't look nice with the new buttons, it never looked nice before with the old structure.

BTW, I would add “helvetica” after arial to the CSS. AFAIK, it is the standard on OSX.

Why not setting Helvetica as the first font?

The date-format is d.m.Y. Fine for en-uk, but confusing for en-us.

Where do you want to change the date format? Do you mean the language file? Maybe we need a separation of British English and American English?

Yes and no. Of course the admin could change the date format in the language file.

Until the next update ...

Two english files – don’t think that it is necessary.

Why not?

I still think that the ISO-format should be preferred in all files.

I disagree, Sire. Having the ISO-format for use in technical contextes is o.k. but for human readability we should use the local common date format.

An old story: When I’m logged in (mix view) and log out, I end up in thread view. However, when I’m in board view, I end up in the mix view (set as the default in the installation).

Jaja. ;-)

Question: In *_userdata user_name is utf8mb4_unicode_ci varchar(64). OK, makes sense.

That's because the column has an index and with utf8mb4 tehre is the problem, that the index has a maximal lenght of 768 Bytes that gets outperformed by the column length (i.e. 255 chars (old definition) are 1024 bytes with only 4-byte-chars (for more details please ask by e-mail in German language)). So I orientated myself on the userdata table, where the column for user name (name) has a length of 64 chars.

But why in *_entries name is utf8mb4_unicode_bin varchar(64) and edited_by is utf8mb4_unicode_ci varchar(255)?

The collation utf8mb4_unicode_bin is necessary because with the often used collation (utf8mb4_unicode_ci) the database can not distinguish i.e. between "Anni" and "Änni". For the column edited_by this is not so critical but in case of the user name it is (i.e. search for already allocated user name).

Cosmetics: Since the content is delivered as HTML5, you can drop the / in same tags (br, closing img).

Yes, but on the other hand it is not wrong.

Helmut01 commented 4 years ago

Hi Auge,

Playing the ‘newbie’ I followed the text which states “For experts”

I'll look into it to make things more clear. If you (or someone else) have (has) ideas, I'm open for proposals.

Maybe in *_add.php() $lang_add['inst_db_settings_d'] "The forum requires a MySQL database. Your webhoster probably already applied one. Please make sure that it is encoded in “utf8mb4_unicode_ci” before proceeding. etc. etc."

I made a fresh install. Same, strange. In install.php $settings['quote_symbol'] = "»"; and the file is encoded UTF-8.

Hmm ...

Checked again PHP Version 7.3.3. Core default_charset Local Value UTF-8 Master Value UTF-8. Duno.

Oh, I thought to have changed all script files. Do you have a list of affected files oy found?

english.php, english_add.php, board.php, db_settings.php, delete_cookie.php, forum.php, forum_entry.php, inc.php, index.php, info.php, login.php, more_smilies.php, rss.php, search.php, timedifference.php, upload.php.

I recoded all in the meantime. If you make me a collaborator on GitHub (grusel) I could provide them. Attaching *.php here does not work.

Another story: When I reply to a post, I see the Category: select-box but it is empty Should we hide it instead? Not sure.

No, the user should see the category name. But as it's not editable, it can be shown in a text element, i.e. in p or in a theme for modern browsers in output.

Makes sense.

BTW, I would add “helvetica” after arial to the CSS. AFAIK, it is the standard on OSX.

Why not setting Helvetica as the first font?

I order fonts like this: First the one I prefer, then in decreasing order based on the operating systems. IIRC, verdana is available since Windows NT. I was wrong with helvetica (see there for defaults of different operating systems).

Yes and no. Of course the admin could change the date format in the language file. Until the next update ...

Correct.

Two english files – don’t think that it is necessary. Why not?

Up to you. Apart from “authorization/authorisation” the date-format definitely differes between en-us and en-uk.

I still think that the ISO-format should be preferred in all files.

I disagree, Sire. Having the ISO-format for use in technical contextes is o.k. but for human readability we should use the local common date format.

Fine with me. BTW, In Austria the ISO-format is the legally binding one since the late 1970s. Given, only nerds use it. ;-)

Question: In *_userdata user_name is utf8mb4_unicode_ci varchar(64). OK, makes sense.

That's because the column has an index and with utf8mb4 tehre is the problem, that the index has a maximal lenght of 768 Bytes that gets outperformed by the column length (i.e. 255 chars (old definition) are 1024 bytes with only 4-byte-chars (for more details please ask by e-mail in German language)). So I orientated myself on the userdata table, where the column for user name (name) has a length of 64 chars.

Hey, I follow your posts in mlf2. ;-)

But why in *_entries name is utf8mb4_unicode_bin varchar(64) and edited_by is utf8mb4_unicode_ci varchar(255)?

The collation utf8mb4_unicode_bin is necessary because with the often used collation (utf8mb4_unicode_ci) the database can not distinguish i.e. between "Anni" and "Änni". For the column edited_by this is not so critical but in case of the user name it is (i.e. search for already allocated user name).

Wow!

Cosmetics: Since the content is delivered as HTML5, you can drop the / in same tags (br, closing img).

Yes, but on the other hand it is not wrong.

Sure.

Edit: Fuck! I closed the issue. Can you re-open it?

auge8472 commented 4 years ago

I closed the issue. Can you re-open it?

Sure, I can. :-)

auge8472 commented 4 years ago

Oh, I thought to have changed all script files. Do you have a list of affected files oy found?

english.php, english_add.php, board.php, db_settings.php, delete_cookie.php, forum.php, forum_entry.php, inc.php, index.php, info.php, login.php, more_smilies.php, rss.php, search.php, timedifference.php, upload.php.

Dubious. All these files have charset UTF-8 in all my text editors (Notepad++, Bluefish).

auge8472 commented 4 years ago

If you make me a collaborator on GitHub

For collaboration it would be enough to fork the repo, to apply your changes to a separate branch and to open a pull request with your changes. But if you really want (not that the "Grusel" would speak for this way ;-)), I also can make you a collaborator in my repo. :-)

Helmut01 commented 4 years ago

Dubious. All these files have charset UTF-8 in all my text editors (Notepad++, Bluefish).

Strange indeed. The original ones show up as UTF-8 in Notepad++. The ones I saved as UTF-8 in Notepad2.4.2.25 are showing up again as ANSI. Forget it.

Helmut01 commented 4 years ago

For collaboration …

No, THX. I don’t feel qualified.

bttrx commented 4 years ago

Date format: How about decoupling the date format from the language file and putting it to forum_settings instead?

Fresh install defaults depending on the selected language:

But allow the admin to change the format during install.

Helmut01 commented 4 years ago

Hi Robert,

sounds great. I would add:

Interesting the W3C.

bttrx commented 4 years ago

DD/MM/YYYY or ISO

Making a default from an or is not possible. So let's take DD/MM/YYYY and allow the installing person to change it to ISO.

We can make it even more complex by letting each user set his own date format for display. ;-)

auge8472 commented 4 years ago

French: DD/MM/YYYY or ISO (both in use)

Making a default from an or is not possible.

… and there the advantage of a setting breaks (not, that it would be simply possible with a value from the language file). :-/

I know, it's not completely comparable but the game OpenTTD is available in several languages even with ones with distinctions between country or region specific definitions. As examples: English (UK), English (AU), English (US) or Norwegian (Bokmal), Norwegian (Nynorsk), simliar distinctions in Chinese, Portuguese or Spanish languages.

So I don't see a reason to separate this from the language file (we can have several of them) and to put it into the settings, where it would be hardcoded for every user of a forum, independent of her/his language or home country.

The alternative to put it into the user settings would IMHO be worse because every single registered user has to set the date format separately (if necessary). This is IMHO no good solution. Selecting only the UI-language (maybe with a distinction between language variants) is simple and good enough.

auge8472 commented 4 years ago

Also: during the work on the old 1.8 (Alfie runs a intermediate result of the work) I introduced a second time format in the language files for formatting timestamps directly in database queries (type SELECT). It's only an example of what's possible in the language files.

A long date format with month names instead numerical notations, a format with weekday names, a short format, similar formats in the database-syntax and so on.

Helmut01 commented 4 years ago

DD/MM/YYYY or ISO

Making a default from an or is not possible.

Haha, sure! Was meant as a verbatim suggesting not for coding.

So let's take DD/MM/YYYY and allow the installing person to change it to ISO. We can make it even more complex by letting each user set his own date format for display. ;-)

Please, no. Opens Pandora’s box. ;-)

Helmut01 commented 4 years ago

I know, it's not completely comparable but the game OpenTTD is available in several languages …

Wow!

The alternative to put it into the user settings would IMHO be worse because every single registered user has to set the date format separately (if necessary). This is IMHO no good solution. Selecting only the UI-language (maybe with a distinction between language variants) is simple and good enough.

Agree.

bttrx commented 4 years ago

Please, no. Opens Pandora’s box. ;-)

I'm just pointing out options. ;-)

bttrx commented 4 years ago

The alternative to put it into the user settings would IMHO be worse because every single registered user has to set the date format separately (if necessary). This is IMHO no good solution. Selecting only the UI-language (maybe with a distinction between language variants) is simple and good enough.

"has to set" is wrong. By default every user would use the forum's setting. If he disagrees, he can change it to fit his needs.

But yes, one more setting here and there would the make forum larger and larger and more error-prone. Let's follow KISS. (Not the band. 🤣)

auge8472 commented 4 years ago

The alternative to put it into the user settings would IMHO be worse because every single registered user has to set the date format separately (if necessary).

"has to set" is wrong. By default every user would use the forum's setting. If he disagrees, he can change it to fit his needs.

Thatswhy I wrote "(if necessary)".

But yes, one more setting here and there would the make forum larger and larger and more error-prone. Let's follow KISS. (Not the band. 🤣)

Making the forum larger and larger is in itself not a problem. Making the operability more complicated is a problem. Making the usability by the users more complicated makes it more error-prone and that's a problem. Making the code more error-prone is a problem. And last but not least, say nothing against KISS (Yes, the band. 😉)!