starred/WiFiManager

Fork 0

mirror of https://github.com/tzapu/WiFiManager.git synced 2026-04-27 00:55:52 +03:00

[GH-ISSUE #1051] Refactor: static ip flags #897

New issue

Open

opened 2026-02-28 01:27:33 +03:00 by kerem · 5 comments

kerem commented

2026-02-28 01:27:33 +03:00

Owner

Originally created by @dontsovcmc on GitHub (May 11, 2020).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/1051

Sorry if I don't understand all use cases, but doubling static ip flags '_disableIpFields' '_staShowStaticFields' looks terrible.

There are only 2 cases:

User wants to use static ip address to connect to internet
User wants to use DHCP

I can refactor it, if needed.

P.S. It will be interesting to research statistic of using WifiManager methods.. I think there are only few popular cases. Others are brake the development.

P.P.S. optionalIPFromString also is outdated.

Originally created by @dontsovcmc on GitHub (May 11, 2020). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/1051 Sorry if I don't understand all use cases, but doubling static ip flags '_disableIpFields' '_staShowStaticFields' looks terrible. There are only 2 cases: 1. User wants to use static ip address to connect to internet 2. User wants to use DHCP I can refactor it, if needed. P.S. It will be interesting to research statistic of using WifiManager methods.. I think there are only few popular cases. Others are brake the development. P.P.S. optionalIPFromString also is outdated.

kerem added the

Discussion

Documentation

labels

2026-02-28 01:27:33 +03:00

kerem commented

2026-02-28 01:27:34 +03:00

Author

Owner

@tablatronix commented on GitHub (May 11, 2020):

It is so you can force showing the fields if you are setting them in code or from elsewhere.

Maybe you can be more specific with what the problem is?
Do you mean confusing?

_disableIpFields is special case, it is not exposed with a setter for that reason

Do you have an idea how to clean it up ?

@tablatronix commented on GitHub (May 11, 2020): It is so you can force showing the fields if you are setting them in code or from elsewhere. Maybe you can be more specific with what the problem is? Do you mean confusing? _disableIpFields is special case, it is not exposed with a setter for that reason Do you have an idea how to clean it up ?

kerem commented

2026-02-28 01:27:34 +03:00

Author

Owner

@tablatronix commented on GitHub (May 11, 2020):

P.P.S. optionalIPFromString also is outdated. ?

@tablatronix commented on GitHub (May 11, 2020): P.P.S. optionalIPFromString also is outdated. ?

kerem commented

2026-02-28 01:27:34 +03:00

Author

Owner

@dontsovcmc commented on GitHub (May 11, 2020):

i can't understand why somebody hardcode static ip and don't want to show it on the menu
i don't have any problem. i think we should simplify source code.
i don't understand the function of _disableIpFields
optionalIPFromString uses to ESP8266 core 2.1.0 message. it's outdated, so we can remove it and use

IPAddress ip;
  if (ip.fromString(server->arg(FPSTR(S_ip)))) {
    _sta_static_ip = ip;
  }

also should be changed to IPAddress class functions:
isIp()
toStringIp()

@dontsovcmc commented on GitHub (May 11, 2020): 1. i can't understand why somebody hardcode static ip and don't want to show it on the menu 2. i don't have any problem. i think we should simplify source code. 3. i don't understand the function of _disableIpFields 4. optionalIPFromString uses to ESP8266 core 2.1.0 message. it's outdated, so we can remove it and use ``` IPAddress ip; if (ip.fromString(server->arg(FPSTR(S_ip)))) { _sta_static_ip = ip; } ``` 5. also should be changed to IPAddress class functions: isIp() toStringIp()

kerem commented

2026-02-28 01:27:34 +03:00

Author

Owner

@dontsovcmc commented on GitHub (May 14, 2020):

@tablatronix offtopic: Why getWiFiSSID()= WiFi_SSID() & getWiFiPass()=WiFi_psk() functions were added? There are the same...

@dontsovcmc commented on GitHub (May 14, 2020): @tablatronix offtopic: Why getWiFiSSID()= WiFi_SSID() & getWiFiPass()=WiFi_psk() functions were added? There are the same...

kerem commented

2026-02-28 01:27:34 +03:00

Author

Owner

@tablatronix commented on GitHub (May 14, 2020):

They are public helpers, have better names, atm they are just aliases, but if we needed to have different logic for internal wrappers and public ones, we can change them. This is for future abstractions. It also gives us public methods to add docblocks to for auto documentation

@tablatronix commented on GitHub (May 14, 2020): They are public helpers, have better names, atm they are just aliases, but if we needed to have different logic for internal wrappers and public ones, we can change them. This is for future abstractions. It also gives us public methods to add docblocks to for auto documentation