Forum Replies Created

Viewing 15 replies - 1 through 15 (of 643 total)
  • Plugin Contributor alexanderzagniotov

    (@alexanderzagniotov)

    Thank you for your financial advise and the time you have taken to write me this message.

    I do value any feedback I can get. I will keep your advise in mind for the next time when I am going to be in a similar situation.

    Regards,
    Alex

    Plugin Contributor alexanderzagniotov

    (@alexanderzagniotov)

    Hi All…

    Some additional remarks to my initial comment about the future of CGMP:
    Yes, I already transferred the ownership of the repository to Robert, as he was responsible for the latest release which fixed the incompatibility with WordPress 4.0.

    If Robert wanted the plugin to “die”, he would have deleted the repository and not helped fixing the broken version. As I know Robert, it is not unlikely that he will make a new release if e.g. an incompatibility with a new WordPress version arises that can be fixed quickly.

    On the other hand I understand that he focuses on developing his own plugin Maps Marker Pro and will probably not add any new features to CGMP. But as said before: Every developer interested in building upon my work can take the code as it is licensed under the GPL, create a new plugin and publish it in the WordPress repository.

    I do understand your point @cogitoergosum when you’re saying “However, it’s also depriving a motivated developer to adopt a successful plugin to make it live properly.”

    That being said, let’s face it: it took me more than 3 years with hundreds of hours of work and many users to get the plugin where it is now. It would also have motivated me more and made things easier for me if I could have built upon a large user base and did not have to start from scratch (which wouldn’t be the case with CGMP as my code can be reused) – just because it is open source does not mean you get everything for free.

    Thank you all again for your support, feedback and criticism you all have provided me over the time…

    Regards,
    Alex

    Plugin Contributor alexanderzagniotov

    (@alexanderzagniotov)

    I tried my best to make things super intuitive which seems to be working for most. But off-course it is not possible to make everyone happy. Therefore, we do have a support forum for people who do not understand how to use the plugin and require some help.

    Thank you,

    Regards,

    Alex

    Plugin Contributor alexanderzagniotov

    (@alexanderzagniotov)

    Yeah, you are using W3 Total Cache. Which means you are not enjoying the cached map data from the server side. Every time you load a page it will try to revalidated the addresses.

    Can you do the following for me:

    1. Deactivate W3 Total Cache for a minute or two
    2. Once W3 Total Cache deactivated, load the page with the map three times (on the first time the addresses will be geo validated by Google, on two subsequent times you should see page load speed improvement)
    3. Activate W3 Total Cache and try to load page with the map again.

    Plugin Contributor alexanderzagniotov

    (@alexanderzagniotov)

    v9.0.20 is giving the same error about your KML.

    Can you try not using the shortlink: “https://goo.gl/maps/KJvwl” ? Can you try using the full URL? Also, this KML has only one marker… why do not you configure this marker in the plugin without using KML?

    Plugin Contributor alexanderzagniotov

    (@alexanderzagniotov)

    Can you provide a link to your page with map?

    That’s very odd as it should not take so much time only for 20+ addresses. Even so, it should only take longer on the first time the page with map is loaded, as any subsequent page load should be fast because all marker addresses would be already geo validated by Google and cached.

    Are you using any caching plugins on your site?

    Plugin Contributor alexanderzagniotov

    (@alexanderzagniotov)

    Thank you

    Plugin Contributor alexanderzagniotov

    (@alexanderzagniotov)

    Thanks ??

    Plugin Contributor alexanderzagniotov

    (@alexanderzagniotov)

    It is possible to add as an option, but I am quite busy these days with real work and do not want to start feature development (apart from cases when a bug was discovered). Sorry

    Plugin Contributor alexanderzagniotov

    (@alexanderzagniotov)

    Nope, sorry

    Plugin Contributor alexanderzagniotov

    (@alexanderzagniotov)

    Sorry, not at the moment. Also, I have no plans supporting it anytime soon ??

    Plugin Contributor alexanderzagniotov

    (@alexanderzagniotov)

    Since you mentioned header.php I tend to think it was your theme’s developer who hardcoded it there.

    But, now, you are using latest jQuery shipped with WP together with migrate plugin. Even if your theme needs an older jQuery, the migrate plugin is there for you

    Plugin Contributor alexanderzagniotov

    (@alexanderzagniotov)

    Sorry, I was on the go last time and my reply to you does not make much sense. Please find a more adequate response:

    The active jQuery version on your site is 1.6.1. It is one of your plugins (or perhaps the theme itself) loaded an outdated jQuery in your site’s FOOTER from external CDN: https://ajax.googleapis.com/ajax/libs/jquery/1.6.1/jquery.min.js . The latter disabled jQuery v1.10.2 shipped with your WordPress by default (which was loaded in your site’s HEADER). I will explain what it means for you.

    But before, I want to point something out: it is a an excellent practice to load JS resources from external CDNs (it can speed up page load time, etc.). But having said that, your website now is restricted to jQuery v1.6.1 only.

    A much more flexible and elegant solution here would be to check the jQuery version shipped with WordPress by default, and load THAT jQuery version from external CDN. Using the latter way, it would be ensured that the WordPress eco system uses the same version as the jQuery shipped with WordPress by default.

    Now, you are stuck with an outdated jQuery in your FOOTER that messes up behavior of plugins (like mine for example and plugin “jquery-archive-list-widget” which is loaded on your blog page) that rely on jQuery shipped with WP by default, because some developer did not want to do extra work and conveniently loaded the version he needed in your FOOTER.

    I do see that you have included jQuery migrate plugin, but it is not going to work in this case. What jQuery Migrate plugin is ACTUALLY does: it prevents plugins and scripts that are using deprecated functions from breaking when you use jQuery 1.9+. In your case, the jQuery ACTIVE on your site is 1.6.1, so the migrate plugin is of no help here.

    The solution I can offer you is:
    (a) Try to identify what is loading the outdated jQuery and eliminate it
    (b) If you cannot/do not want/not able to do (a), try using another Google Map plugin because I am not going to make my plugin compatible with jQuery version older than 1.9.

    I hope this helps and I apologize for inconvenience.

    Plugin Contributor alexanderzagniotov

    (@alexanderzagniotov)

    Ok…

    @djey-

    The active jQuery version on your site is 1.6.1. It is one of your plugins (or perhaps the theme itself) disabled jQuery shipped with your WordPress by default and instead an outdated jQuery was loaded from external CDN: https://ajax.googleapis.com/ajax/libs/jquery/1.6.1/jquery.min.js I will explain what it means for you.

    But before, I want to point something out: it is a an excellent practice to load JS resources from external CDNs (it can speed up page load time, etc.). But having said that, your website now is restricted to jQuery v1.6.1 only.

    A much more flexible and elegant solution here would be to check the jQuery version shipped with WordPress by default, and load THAT jQuery version from external CDN. Using the latter way, it would be ensured that the WordPress eco system uses the same version as the jQuery shipped with WordPress by default.

    Now, you are stuck with an outdated library that messes up behavior of plugins (like mine for example) that rely on jQuery shipped with WP by default, because some developer did not want to do extra work and conveniently loaded version that he needed.

    I do see that you have included jQuery migrate plugin, but it is not going to work in this case. Before I explain “why”, I want to note that I made a typo a couple of posts earlier when I spoke about jQuery Migrate plugin – the migrate plugin should be used when you have jQuery 1.9+:

    What jQuery Migrate plugin is ACTUALLY does: it prevents plugins and scripts that are using deprecated functions from breaking when you use jQuery 1.9+. In your case you are using jQuery 1.6.1, so the migrate plugin is of no help here.

    The solution I can offer you is:
    (a) make sure you are using jQuery 1.9+ by identifying what is loading the outdated jQuery.
    (b) If you cannot/do not want/not able to do (a), try using another Google Map plugin because I am not going to make my plugin compatible with jQuery version older than 1.9.

    I hope this helps and I apologize for inconvenience.

    Plugin Contributor alexanderzagniotov

    (@alexanderzagniotov)

    Just make sure that the active jQuery on your site is of version 1.9+. I say “active” is because some plugins/themes disable loading of jQuery shipped with WordPress by default and instead load older versions.

    Also, if you ARE using an older jQuery than version 2.9 (maybe due to your theme) and cannot upgrade, please make sure you have installed and activated jQuery Migrate plugin (https://www.ads-software.com/plugins/jquery-migrate/)

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