Forum Replies Created

Viewing 15 replies - 1 through 15 (of 34 total)
  • You can fix it like this:

    
    .ebg-br-wrapper > .ebg-br-background-image {
      height: 33px;
      left: auto;
      right: 0;
      width: 33px;
    }
    
    shamank

    (@shamank)

    Thanks. I think you’d need to add this in some docs. I checked plugin code yestarday until I finally found the answer myself (I was about to make a post today about it), but most of people using wp are not devs and can’t do that. I couldn’t find any docs about your plugin, more than support page itself. Did I miss something? Thank you.

    @alberto3 Exactly!

    Mmm maybe there’s a misunderstanding here… I’m not sure my point is being understood, or maybe I’m not understanding you?. My english may not be the best (I’m a spanish native speaker).

    I’m not referring to categories or tags, that works good as always did. What I’m saying is related to cache of views in mapped domains. I’ll try with this example:

    Case 1: Drop cache for single page.

    1. I Have my main domain “mydomain.com”, which I use to host several landing pages. One of them is called “Page A” with URL “/aaa”. So when I go to “mydomain.com/aaa” I see that page (Page A).

    2. I have this multidomain plugin, which I use to map/connect “mydomain.com/aaa” with “aaa.com”. So when I go to “aaa.com” I see the contents of “mydomain.com/aaa”.

    3. Fastest cache: When I go to “mydomain.com/aaa” it creates a cached view in “wp-content/cache/mydomain.com/all/aaa/index.html”, so it serves this view, which is ok.

    4. Fastest cache: When I go to “aaa.com” it creates a cached view in “wp-content/cache/aaa.com/all/index.html”, so it serves this view, which is ok.

    5. I make a small change in “Page A”, so I want to drop the view cache for only this page (like saving, with the proper config in Fastest cache plugin, or just hiting the button to drop only cache for this single page, like the link you provided with tutorial).

    6. Fastest cache: it deletes the view in “wp-content/cache/mydomain.com/all/aaa/index.html”, so if I go to “mydomain.com/aaa” I see the applied change. This is ok. However, it doesn’t delete “wp-content/cache/aaa.com/all/index.html”, so if I go to “aaa.com” I’ll still seeing the old cached page, with the old contents.

    Case 2: Drop all cache

    1,2,3,4 => same as before

    5. I make a change in a theme feature or a component that require all views to be cleared. So I hit in the top bar button “empty all cache” (I have it in spanish so I don’t know the english name… I guess it is something like that).

    6. Fastest cache: it deletes all views in “wp-content/cache/mydomain.com/all/*/index.html” (all URLS, like “/aaa”, “/bbb”, “/xxx”…), so if I go to “mydomain.com/aaa” or “mydomain.com/bbb” I see the applied change. This is ok. However, it doesn’t delete “wp-content/cache/aaa.com/all/index.html”, so if I go to “aaa.com” I’ll still seeing the old cached page, with the old contents. Same if I have other mapped domains, like “bbb.com”. It only deletes all views in my current main domain “mydomain.com”.

    So my proposed solution is to delete all index.html (and wpfc-minified files) in all directories, not only in “mydomain.com”, when you hit “empty all cache”.

    The next step would be to clear cache for single pages (like deleting “/aaa” and “aaa.com” cached views when saving “Page A”).

    Thank you.

    Yes, I already do that, but it doesn’t remove cache for the associated domain, just the URL. For example, I have a landing page A in “/aaa”, and it’s connected (through this multisite plugin) to “aaa.com”. When I flush cache (single page method or full cache), it correctly removes cache for “/aaa”, however cache at “aaa.com” is still there. So, let’s say I make a change in page A, flush cache (any method), and change is visible in “/aaa” (as supposed to), but “aaa.com” is still showing the old page (forever).

    I know it can be difficult to implement individual page cache cleaning to mapped domains because it’s an individual implementation for each multisite plugin. You can’t know the mapped domain unless you know how plugin made it, and they are all custom implementations.
    An option could be to save the real URL path as a comment in your plugin comment at the end of the page (like “<!– WP Fastest Cache file… wp-fastest-cache-path:/aaa …” so you can grep that specific value) and then remove cache from all pages containing that URL, so you would be also removing cache layer from other mapped domains targeting the same page.

    Anyways, if “flush all cache” (global) would remove cache from all pages (removing all cached views like wp-content/cache/*/all/index.html) then it would be a partial solution I guess.

    Thank you!

    You are absolutely right with that, but we are using Avada as the main theme and it has “global blocks” to share code among different pages (you change code in a single place instead of going one on one). We use a common block (layout) for footer and some internal elements. In those cases, I’d need to flush everything to update all views. Other case is a form reused in different pages. You change something in a form (contact form 7 page) and it must be updated in all pages using it.

    BTW, it would be great to flush only the cache of a single page instead of removing the entire cache (on small modifications), but I think it wouldn’t be possible for you unless you make some special support for every multisite plugin (like the one I’m using: “Multiple Domain Mapping on Single Site” => https://wordpress.org/plugins/multiple-domain-mapping-on-single-site/), right? Because you wouldn’t know the mapped domain unless you query the specific plugin object.

    Thank you!

    Flushing the entire cache, shouldn’t be removing all static views/resources, regardless urls?

    Hi again! @emrevona Today I noticed a little trouble with cache. When I drop view and scripts cache (from plugin or button in top bar), cache for the mapped domains is not being flushed, and cache files persist in file system:

    This line shouldn’t be there after flushing cache:

    # ack CompleteRegistration
    wp-content/cache/getyourplan.access-one.us/all/index.html
    116:fbq('track', 'CompleteRegistration');
    

    If I go through URL (…/access-one-seguros-medicos-internacionales/) it’s not definetely there.

    Thank you!

    • This reply was modified 11 months, 1 week ago by shamank.
    • This reply was modified 11 months, 1 week ago by shamank.

    @emrevona Done! BTW since I installed a “static” version of your plugin, will I see new updates in manager? In case not, could you please let us know here when this change/fix is released so I can reinstall it from wp store? Thank you!

    You are a genious man, thank you, it works!! 😀

    Thank you @emrevona ! I’ll try and let you know the results 🙂

    Thank you for your fast answer and work! Have a nice day.

    Hi Emre! First of all, thank you for your incredible work. This plugin is a “must have” plugin all wp sites need, and I like it more than other similar ones. Just wanted to tell you 🙂

    Well, I’m adding myself to this thread since I’m experiencing an issue I think is similar to multi site support. I’m using a plugin to be able to map URLs to different domain: “Multiple Domain Mapping on single site” (plugin name). I built kind of a landing pages website. What is happening to me is that cache is being captured by other domains/pages. For example:

    Page A (example.com)
    Page B (other.com)
    — destroy cache —
    User requests Page A => Returns Page A (ok)
    User requests Page B => Returns Page A (bad)
    — destroy cache —
    User requests Page B => Returns Page B (ok)
    User requests Page A => Returns Page B (bad)

    May it be that cache is being returned just checking the URL instead of DOMAIN + URL? So, “example.com” become “/” and “other.com” become “/”, so plugin assumes it’s the same page being requested.

    Any chance to take a look at this, please? I’d really appreciate it. Thank you!

    That’s great man! Sharing progress bar time among all parallel uploads is a good idea to handle this. It works even if I start an upload and then I click again and I add a file that’s gonna fail.

    However, I can see another bug now. It’s not as important as the other one, but it would be a fine improvement.

    If you start an upload of, let’s say, 5 files of (let’s say) 10 MB, send button gets disabled as expected. So the upload of 50 MB starts. If you cancel all of them, send btn will be still disabled and will wait to those 50 MB files to finish uploading before enabling it back. So the user won’t know what really happened and they won’t be able to send the form until internal uploading process is finished.
    I think you could save the reference of the AJAX connection (in an object scope/global array, since lot of connections may occur at the same time) and abort them in case the user cancels the opperation. I’m not sure if success or fail event will be triggered (I’d assume the fail one), but I think you would be able to handle the abort opperation to perform the right actions after it.

    Thanks man!

    • This reply was modified 1 year, 7 months ago by shamank.

    Thank you Glen!

    Have a nice end of week.

    Thank you guys. I’m a developer, however I’m not a WP developer (I have basic knowledge about WP structure and hooks). I’ll add `register_post_type(“event_listing”, apply_filters(“register_post_type_event_listing”, $args_events));
    ` to my child’s functions.php. Do I need to pass the entire array ($args_events) or is it enough just by passing the ‘rewrite’ key?

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