Cloud Development

Forum Replies Created

Viewing 15 replies - 1 through 15 (of 18 total)

  • @uwejacobs Yes, this seems to be the problem.
    The browser-location-popup is a nag in persistence of returning.

    Yes: I think that for OWM-Weather plugin, its worth to store the given browser-location with a refresh-browser-location-time(if setting is enabled). Min/max visitor-browser-location-refresh-rate + ‘Last-used cached-weather-object’ logic, perhaps helps to reuse/combining of ‘aggressive-moving’ visitors and there ‘browser-location-cache’ pop-up on the client-side. trough many rogue-visitors(who just-don’t-care) resulting in a endlessly querying of non-buffered weather-objects…

    Current plugin-condition no-website-visitor becomes happy, with a endless(never quieting) browser-location-popup. Currently the only solution is to force/store allow/block the location-popup at the browser…

    ——————–
    Doesn’t HTML5 support: browser-location-data ‘accessible and allowed’?, before pooling every page-visit? I’m understanding that ‘Visitor-location-caching’ has a shorter ‘usable-lifetime’ than ‘weather-object-caching’.

    *Client-browser-Location-cache-refreshing-time, could be a plugin-setting (some plugin use-cases could require: live, 10 minutes, every-page-hit, once(stored in cookie)).
    *Location-refresh-icon’on/off’ (next to the location-city-name), to disable/enable ‘browser-location-website-request’ feature(and cookie it).
    ——————–

    I think it could also help with the ‘total amount of Open-weather queries’, being generated by unwanted(and unregulated/managed) varieties of Open-weather-queries deriving from visitor-use of this plugin(compliments and thank your making).

    Thank you for the ‘zooming-out’ from ‘town-name’, to ‘planet-name’. This saves the globe ‘OpenWeather-API calls’ and a dramatic improves data-accuracy, when using ‘visitor-location’ feature.
    Almost there!

    I’m looking forward to your replay.
    With kind regards,

    Thread Starter Cloud Development

    (@clouddevelopment)

    Dear Jacobs,

    After your upgrade of this plugin trough this topic, the circle became clickable.

    But this did not solve my initial problem with the endless-loading icon(inside the website-widget). A loading-problem(endless rotating loading-icon), where a full-page-refresh was the only workaround/fix.

    I think the endless loading could come from a AJAX-API call, that results in a error(not tested yet to confirm).

    But is it true that a AJAX-API call from the front-end weather-widget(what results in a e.g. PHP error) requires a ‘full-hard-page-refresh’ to be fixed?

    —————————
    Is it possible to add two stages to the clickable loader:
    1) ‘Default-Loading Icon’ (with ‘non-clickable-timeout option’ before clickable re-start of the AJAX-Call; first/single refresh attempt).
    2) ‘Second-attempt-Loading Icon’ (with same timeout option to clickable ‘Hard Browser Reload-button’ gets clicked manually, resulting in a full-hard-refresh of the website its page.
    3) ‘Third-attempt-loading failed’ message(non clickable), if the ‘full-page-reload’ doesn’t fix.

    Perhaps with timeout-status change message like:
    1) ‘Unable to load, click to retry’
    2) ‘Something is wrong. Please click to fully-reload the page.’
    3) ‘Permanent Error, reference to plugin-debug documentation.’
    —————————

    Some input/thoughts for usability and debugging.
    I will look in the AJAX error hypothesis later, but I thought this ‘clickable error-loading’ could help with error-handling.

    Looking forward to your replay,
    Kind regards,
    Sven

    Thread Starter Cloud Development

    (@clouddevelopment)

    Hi John,

    Thank you for your quick replay.

    Selecting a predefined 404-page and using a 404-redirect plugin is indeed the solution to partly-fix this bug. If the ‘hiding wp-admin/wp-login(or others)’ feature for redirected-URL’s is disabled(or default, not-selected/disabled), the default WordPress 404-error functioning should be triggered/working when hiding a URL.

    But that solution is not a fix for the two not working ‘features'(given below and above). But this solution is no fix, to make HideMyWP its hidden folders/paths feature working(not breaking).

    Meaning that these two features are not working
    Two options in ‘Redirect Hidden Paths:’:
    *404 page
    *404 HTML Error

    I can help with basic-debugging.
    Please advise,

    Thread Starter Cloud Development

    (@clouddevelopment)

    ‘Redirect Hidden Paths:’ is set to ‘Home page’.

    Do Login & Logout redirects is turned on.
    Login -> empty
    Logout -> /

    Thread Starter Cloud Development

    (@clouddevelopment)

    Log-out redirect seems to be working again when I disable: “Change Paths -> Login Security -> Hide WP-Login.php” and ‘Hide Login path’

    Thread Starter Cloud Development

    (@clouddevelopment)

    “Clean Login Page”-setting, on/off also makes no difference at “Advanced -> Compatibility”.

    Thread Starter Cloud Development

    (@clouddevelopment)

    Ahhh, bummer……

    Not Found
    The requested URL /wp-login.php?loggedout=true was not found on this server.

    While returning to previous page trough the browser-back button+hard-page-refresh gives me a successful ‘please login again’ replay(so the session is ended successfully, but the redirect is still non-existing…

    Happening when login-out of a sub-site(not the main-site), inside a multisite-setup environment(with this plugin).

    With kind regards,

    Thread Starter Cloud Development

    (@clouddevelopment)

    Dear @johndarrel,

    Yes, the update is working.

    The logout its redirect for sub-sites(in a multi-site environment) with a renamed wp-login.php now goes smoothly.

    Perhaps the ‘default-suggested input’ of the ‘redirect-logout-url’ input-field(non-existing ‘logout’ page), could also had been of trouble(not sure). url/path/page validation, on ‘redirect-destination input-fields’?

    But, it works now and redirects-smoothly!

    Thank you.

    Dear @uwejacobs,

    Thank you for the update with upgrades.

    I can confirm that the popup, for ‘browser-location request’ is working.

    It has only no ‘website-visitor memory-function’. Every time reloading the page, the browser gives the same message(suggestion: store the guest its previous retrieved location-data in a cookie, to prevent a ‘pop-up location-request’ from the browser, each page-load).

    Also the ‘default’ city ‘IP-location’-name, changed from ‘IP-Location city-name’ to default ‘Globe’. Thinking your making ‘Open Weather’ and many web-hosters happy, with this ECO-friendly default-setting ??

    Thinking out loud: if the browser its location feature of the guest doesn’t provide data, the plugin could switch back to IP-location data. On the moment IP-location is used by the plugin, the country location(or capital) could be used(in stead of town-name related to IP what is almost always a mismatch).

    Using town-location when browser-location data is available is a more certain condition/situation where guest-location and matching become effective(and so less or no false/wrong location results).

    Cool idea. Challenge in keeping spam-location-submits out. Also making it user-friendly with validating the input to actual geo-data request(and the source of this data to match/validate). Although the plugin is free, the amount of ‘free’ weather-data requests is limited to website-owners.

    Could lead to a lot of filtering of location-submit-abuse intended for sabotage/spam-traffic.

    I had a kind-a-equal situation where the browser-location-feature/setting: should be nice to out-zoom to country-wide forecast in stead of town-name forecast(helps mismatching guest-geo-location town-name results.). Just zoom out to country, would solve the ‘wrong town-name’ results problem(but the wrong town-location-results, remain always within the right country).

    Could also help with lowering total-used API-calls, but this is not equal to your guest-custom-location-submit feature-request.

    Thread Starter Cloud Development

    (@clouddevelopment)

    Hello @uwejacobs,

    True, I think your current weather-object caching feature is already a useful feature.

    But use-cases of a multisite and how a plugin can be used(and what becomes for a plugin developer available in use-case options): can indeed result in your case to many equal(or matching)-queries, where the weather-object caching ‘currently’ is out of reach(among different subsites).

    But than again, some multisite-setups could like to use different API-credentials for each sub-site. Where a other multisite-setup its use-case could prefer a central-and-single api-setup for your plugin to all sub-sites.

    Query caching and data-mapping could be a brave but large thing to design/build, but the concept of your current weather-object caching is already very efficient.

    Thread Starter Cloud Development

    (@clouddevelopment)

    Hello,

    I tried disconnect. No difference, still getting a

    Not Found
    The requested URL /wp-login.php?loggedout=true was not found on this server.

    page. The logout went successful(session is gone on refresh original page), but even setting the redirect url to / or logout doesn’t make a difference.

    With kind regards,

    Thread Starter Cloud Development

    (@clouddevelopment)

    Hello Jacobs,

    Thank you for replaying.

    Got no idea how your code or data flow works(knowing its on git-hub).

    Caching eventual weather-object’s there data sounds more logic than caching the API calls. Before different weather-objects use the same API-call… Lots of logic for what a custom-API on a self-hosted web-service could buffer as well. But this is more complex for the web-designer/implementer/use-case.

    Above feature is describing a feature to manage all multi-site-wide weather-objects in the central multi-site-admin, and re-use these weather-objects in the eventual sub-sites there WordPress-admin. All sub-sites could use the multi-site wide available weather-objects(managed from the multi-site-admin) and included/implemented them in the sub-sites.

    On this construction, different sub-sites could use the same weather-object its cached data(and configuration setup). Not creating 4equal weather-objects(manually) on 4 sub-sites to generate 4times the same query(and 4 times the effort to setup the same weather-object).

    Also meaning that the data-source its API setup/credentials are managed just ones in the multi-site-admin, and not for each sub-site individually(as is currently).

    Hope this helps giving context to the request feature.
    Best wishes,

    Thread Starter Cloud Development

    (@clouddevelopment)

    Hi Jacobs,

    Thank you for your fast replay and quick fix. Seems to be working different now, not able to validate the button. Respect for fast applying!

    Kind regards,

Viewing 15 replies - 1 through 15 (of 18 total)