currently using, I am unable to access my personal email - Instead, it brings me back to the home page.
Also, on my cell phone (Samsung Galaxy S7, with Android 6.0.1, using its included 'Internet' web browser), there is a button in the upper-right with the text "undefined".
currently using, I am unable to access my personal email - Instead,
it brings me back to the home page.
I can't replicate that here with the most recent updates. You may have updated while I was in the middle of making some changes; I think there was a bug like that very briefly about a week or two ago.
Also, on my cell phone (Samsung Galaxy S7, with Android 6.0.1, using
its included 'Internet' web browser), there is a button in the
upper-right with the text "undefined".
That was fixed some time within the past week.
currently using, I am unable to access my personal email - Instead,
it brings me back to the home page.
I just downloaded the latest ecweb 4 from its GitHub page, and I still see this issue.
I just test ecWeb v4 on my system. But it not support swedish chars.
Is it hard to change that??
I just test ecWeb v4 on my system. But it not support swedish chars.I have no idea. I'll look into it if you can give me an example of how to reproduce the problem.
Is it hard to change that??
I have no idea. I'll look into it if you can give me an example
of how to reproduce the problem.
When I write a message in an lokal area with swedish chars in
(aaoAAO), and then reading it. Subject is ok, but in message it is
only garbage.
Like:
Test aaoAAO
From Fidde to All on Thursday, January 05, 2017 18:59:43
Test |N|n|||a|a|u
And in register, if i write my address or city with swedish chars,
they are missing in useredit, like Molndal is Mlndal.
When I write a message in an lokal area with swedish chars in (aaoAAO), and then reading it. Subject is ok, but in message it is only garbage.
And in register, if i write my address or city with swedish chars,
they are missing in useredit, like Molndal is Mlndal.
Along with updating, you'll need to add the following to the [web]
section of your ctrl/modopts.ini file:
forum_extended_ascii=false
forum_extended_ascii=false
Just updated and gave this a go. Looks like my tagline is now displayed properly there. Well done, my good man!
I've committed some changes today which may help, if you'd like to update and give it a try.
forum_extended_ascii=false
I was stripping all non-ASCII characters out of parameters posted from that form. I've loosened this up somewhat and it will probably work better for you now.
Works fine that too. But why not realname is saved in userbase?
Works fine that too. But why not realname is saved in userbase?
Just updated and gave this a go. Looks like my tagline is now
displayed properly there. Well done, my good man!
The "downside" of this setting is that extended ASCII characters will
no longer be rendered on the web in CP437 lookalikes. You may see
some "garbage" in things like BBS advertisements and other places
where extended ASCII is typically used in BBS messages. That said, I wasn't displaying messages in a fixed-width font, etc., so that stuff didn't display as originally intended anyhow.
Ideally this would be configurable on a per-sub or per-group basis,
but I'd have to think about how best to organize those kinds of
settings.
By: TinTino to echicken on Fri Jan 06 2017 13:11:32
Works fine that too. But why not realname is saved in userbase?
This should be fixed now.
Which I suppose would probably be much easier if something like that was configured in SCFG itself. I believe Deuce was going to venture into UTF-8
support at some point, so you may just be a little ahead of the game here. Maybe have a talk with him before going too much further, and you can
Otherwise, yeah, you'd basically have to have a list of every sub, and
Not sure if you could do something like what you did with the file areas, and have a check for well formed ANSI codes. If so, display it in CP437.
Now I only missing zipcode :)
RE: ecweb v4
BY: echicken to TinTino on Thu Jan 05 2017 15:41:44
I've committed some changes today which may help, if you'd like to update and give it a try.
forum_extended_ascii=false
Thank you very much. Works much better now.
I was stripping all non-ASCII characters out of parameters posted from that form. I've loosened this up somewhat and it will probably work better for you now.
Works fine that too. But why not realname is saved in userbase?
How is the SCFG->System->New User Values->Question Toggls->Allow EX-ASCII in Answers set?
I've committed some changes today which may help, if you'd like to
update and give it a try.
forum_extended_ascii=false
Thank you very much. Works much better now.
I was stripping all non-ASCII characters out of parameters postedfrom
that form. I've loosened this up somewhat and it will probablywork
better for you now.
Works fine that too. But why not realname is saved in userbase?
How is the SCFG->System->New User Values->Question Toggls->Allow EX-ASCII in Answers set?
@H@Ydigital man@n
When called with that option, this function treats each byte as a
single character, and converts those in the 128-255 range to HTML
entities with the same appearance as the corresponding CP437
characters. (▒ for a light-shaded block, for example.) This
would not go well with multibyte characters.
When that setting is disabled, the body as read from the message base
is sent to the browser without going through that particular
conversion (though it is still modified to some extent). If you're
seeing your UTF-8 characters properly in the browser, that would
indicate that SMB isn't mangling them at all (and why would it), so
that's good.
So I doubt if much or anything needs to be done on the Synchronet
side; from what I'm seeing, UTF-8 support is mostly down to how the
client (browser, terminal, etc.) chooses to interpret the data it's receiving. At least with regards to messages. Maybe a
'content-encoding' message header would be helpful, if the BBS had
some way to determine what should be used there.
Not sure if you could do something like what you did with the
file areas, and have a check for well formed ANSI codes. If so,
display it in CP437.
I think I made the assumption that if any characters in the extended description had codes > 127, that I would pass the description through html_encode (as described above) with certain settings. This would not work here, and will also stop working if/when you tell me that you
want support for UTF-8 in descriptions imported from file_id.diz. :D
I update to latest webv4 and it works fine in http. But in https I cant login. The log say:
2019-02-27 14:42:55 1932 TLS dbg 'WSAECONNABORTED: Connection was terminated due to a time-out or other failure' (-42) popping data 2019-02-27 14:42:55 1932 !ERROR 0 receiving on socket
do you now why?
No. This is likely to be a problem with the web server & TLS and not somethi E>I can fix in the web UI.
| Sysop: | Winzlo |
|---|---|
| Location: | Minnesota, USA |
| Users: | 11 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 495934:29:11 |
| Calls: | 82 |
| Files: | 1,070 |
| D/L today: |
27 files (11,920K bytes) |
| Messages: | 286,923 |