Forum Replies Created

Viewing 15 replies - 1 through 15 (of 23 total)
  • Yes, now everything works as it should.

    ..or you can update your plugin’s JavaScript code to use the recomended (and without security issues) version of jQuery?

    I’ll give you 1 star until then.

    Using jQuery 3.3.1, without jQuery migrate. I believe the default jQuery library, shipepd with WordPress is 1.12.4.

    The issue I’m talking is not related tonthe uninstall process (although it would be great for every plugin to clean after itself when user removes it). Also it appears only that you can delete the custom field from the “Custom field control” section from interface. The field is visually removed, but the data remains in postmeta table and in options table (in form of serialized string with all fields). This is issue for me, because I use custom SQL query to get fields currently associated with given custom post type. I’m sure it is a easy-to-fix problem, but I didn’t have time to digg more into the source code of the pligin and fix it by myself.

    Plugin Author Budiony Damyanov

    (@budiony)

    Try the new version 0.8, this problem is fixed.

    However for best results while managing administration area use an modern browser, i.e. Firefox 20+, Chrome 20+, Opera 12+, IE 9+, Safari 4+

    Post here if you still experience the problem and provide me screen-shots/browser details or any other useful information which may help me to identify the issue.

    Plugin Author Budiony Damyanov

    (@budiony)

    Can you provide me more details of which browser you use, or better – a screen-shot ?

    Plugin Author Budiony Damyanov

    (@budiony)

    …and it replaces with regular expressions the more that one space with one only (this is the regex pattern preg_replace('~(\s)\1+~', '$1', $buffer);).

    Plugin Author Budiony Damyanov

    (@budiony)

    Not all blank lines and extra spaces are minified and this is on purpose.

    In fact, there could be more compression applied to the HTML source, but this breaks the inline *JavaScript* code and *CSS*.

    Put in short – the plugin replace the following combinations
    "\t","\r","\t\r","\r\t" from the white-space range.

    Plugin Author Budiony Damyanov

    (@budiony)

    Hi, if you type as new bot identifier “.com”, the plugin will block all requests to your web site, which comes from agents with this text contained in their user-agent string.

    For example, if you add new bot identifier and you type “firefox”, all users, which use the Firefox web browser will not be able to open your blog, because this text is contained in browser’s user-agent identifier.

    I hope I understood your question correctly, if you have something different in mind, share it here again.

    Plugin Author Budiony Damyanov

    (@budiony)

    When you edit the most recent post, it’s own cache file will be re-created on update, not the cache file of the main page, i.e. the cache file for displaying the single post or page.

    If you display some excerpts of recent posts on your main page (for example via custom query loop in your theme), this information will not be updated, because the URL of the main page is different from the URL of the updated post(s).

    The Easy cache plugin perform its job based on the URL of the given page/post. As a work-around, indeed you may manually remove the cached file for your home page (that’s the main purpose of this option in Administration area).

    Plugin Author Budiony Damyanov

    (@budiony)

    The cache is created on first access of the newly published posts / pages . If you have updated the post or page (or you have new comments), the cache file will be again recreated on first access of the updated page/post. So only the cache associated with this page/post will be recreated when page or post is updated, if you have other pages/posts with links pointing to the new posts – like menus, you`ll have to update them too (either place the correct links to that page, or just open and save the page without performing modification, this will trigger the cache recreation mechanism). Or, as final resort (if you do not understand what I’m trying to explain), clear the cached files, they will be recreated automatically on first access.
    If you provide me more specific details on what you have in mind maybe I could help?

    Plugin Author Budiony Damyanov

    (@budiony)

    Update: The solution for wp-polls plugin (and also with any other voting plugin) is to exclude the page or post, on which is the poll, from caching mechanism, because mixing dynamic (polls results or voting options) with static (regular page/post) data is bad idea.

    The reason is that even if we rebuild the cache page / post after visitor’s vote, all other users on the web site will see the last voting user result and they will not be able to vote (because there is restriction by IP address per visitor). So all other visitors will see the results, not the voting options itself, as if they are already voted (because this information will be cached from the previous user).

    Easy cache plugin will not and cannot generate cache pages / posts per user IP address (this is the only way to deal with IP address restriction).

    Plugin Author Budiony Damyanov

    (@budiony)

    Hi, Hussam, indeed using polls is very frequent on blogs, Easy cache was not tested with wp-polls plugin, however stay tuned (again) and I`ll try to implement the solution.

    If you have other proposals for improvement – I`m open to suggestions.

    Take care.

    Plugin Author Budiony Damyanov

    (@budiony)

    Version 0.4 of the plugin adds compatibility support for Jetpack mobile theme from WordPress.com
    It is recommended to check the setting in Administration panel and leave it with its default value.

    Plugin Author Budiony Damyanov

    (@budiony)

    WordPress, by default, does a form of “Object Caching” but its lifetime is only a single page load. Let me explain you what exactly is the Object Cache in WordPress, because I see that you are not familiar with this matter:

    Options (extracted from database table wp_options) are actually a really good example of this. The summary:
    – A page starts
    – All options are loaded with a simple SELECT option_name, option_value from $wpdb->options statement
    – Subsequent requests for those options (eg a call to get_option never hit the database because they are stored with the WP cache API.

    Options always “live” in the database and are always persisted there — that’s their “canonical” source. That said, options are loaded into the object cache so when you request an option there’s a 99% chance that request will never hit the database.
    So to speak, Easy cache plugin make very few requests to the database to get his options and they are all cached, by default by WordPress, so the Object caching is enabled by default (because actually this has nothing to do with the plugin, but with the WordPress system).

    Transients are a bit different, but the Easy cache plugin does not use them.

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