feature/jaswsinc #125
feature/jaswsinc #125
Conversation
|
Noting that MU Domain Mapping tests show that we also need to alter the sub-directory for sub-directory installations--combined with domain mapping. Tricky! |
|
Since this PR includes changes from several different issues, I'm starting a list of things I need to test prior to merging this PR: Things to test before merging this PR
|
…n a future version of WP.
|
@raamdev Just a heads up on this. While working to make ZenCache compatible with domain mapping, it became obvious there were going to be some limitations--in terms of which domain mapping features that ZenCache could support. For instance, I was not previously aware that you could map a single child blog to multiple domains with the domain mapping plugin. So, after I finished the initial work to make ZenCache more compatible with domain mapping, I decided that I would try to make it compatible with all features of domain mapping--not just a few. In order to accomplish this, there was some more work to do in order to make that sort of functionality compatible with automatic cache clearing. For that reason, I went back to work on this and I will push those changes later sometime this week as I continue to work on ZenCache issues. |
Copy that. Thanks for the update. Does that mean we're going to miss our RC deadline of Wednesday, August 5th? I assume this PR can't be merged until you're done with those bigger changes, since all of the other smaller stuff you worked on is now part of this single PR? It would be nice to punt the domain mapping stuff to the following release so that we can stay on target for the August 5th RC and then have more time to work on and test the domain mapping improvements as part of the following release. |
|
Right. I wouldn't use any of the changes in this PR as part of a release just yet. Everything in this PR is still a work-in-progress at the moment, and there are more changes coming to improve upon what I started working with. Having said that. I spent quite a bit of time on this last week, and I don't feel like it's far off. I expect to have this PR ready for a merge in the next day or two. Perhaps by Wednesday, but that will depend on what else happens this week. Can't be sure yet. |
|
Copy that. I'll push the RC and the Next Release 2 days forward. If there's anything specific that I can help with to get the work in this PR ready for an RC by the end of the week, please let me know. :-) |
Tests Completed by @jaswsinc
|
|
Noting that on a multisite network w/ domain mapping, the ACE will look for your sitemap in one place and one place only; the mapped domain. If there is no domain mapping for a particular child blog, the sitemap is pulled from the original domain/path or sub-domain location as usual. In this way there is no need for the ACE to waste time trying to prefetch all possible variations of a domain whenever domain mapping is enabled. We only auto-cache the primary domain for each child site if there is one, else the standard sitemap path for each blog. |
|
@raamdev My testing is complete here. This is ready for another pair of eyes. |
Copy that. Thanks! I'll start testing this now too. |
Tests completed by @raamdev
|
|
@jaswsinc Merged. Woohoo! Nice work! 👍 :-) |
|
Yikes. Now I just need to write changelog entries for all of these changes! |
|
@jaswsinc As I was reviewing some of the issues resolved in this PR I realized that there are several issues that were labeled both wpsharks/comet-cache#368 If the choice is not to fix some of these in the Lite version, then we need to come up with and implement a plan to notify site owners via a Dashboard message (as I described briefly in https://github.com/websharks/zencache.com/issues/65#issuecomment-127499042) so that Lite users do not just assume the bug isn't fixed (resulting in unnecessary reports of bugs, a bad image of our software projected by the Lite version, etc.). I'd like to fix bugs where possible in the Lite version (old codebase), but not if it means a ton of work. I'll definitely need your help in making those judgement calls, as you'll be better at determining just how much work will be needed to fix each bug. My feeling is that things like wpsharks/comet-cache#368 should be relatively easy to fix in the old codebase, but I could be totally wrong. Would you mind taking a look at the above list of issues and letting me know which ones you think will require the least amount of effort to fix in the old codebase? (Note that the last few issues on that list were bugs reports that you opened, so I wasn't sure if they were applicable to the old Lite codebase.) |
|
Can be fixed easily in the lite version. A minor tweak could improve the way this works in the lite version. However, the full fix that we implemented would require significant changes that I would advise against. My suggestion is that we try to implement the easy fix to improve this, and leave the rest as is.
Unfortunately, these are not easy fixes. It's going to require more widespread changes and quite a bit of testing. My suggestion is that we don't try this. The existing Lite version is working quite well for most people. As you mentioned, I think we should try to limit our work on that old copy to bugs that are quick/easy. That way we can stay focused on Lite+ and Pro moving forward. My feeling is that there will come a point where the benefit of offering a more up-to-date Lite+ version will outweigh the benefits of distributing the old Lite version that is more compatible with PHP 5.3 and APC. So we will have Lite and Lite+. Every once in awhile, the Lite version could be updated so that it actually becomes a mirror of Lite+; i.e., in order to bring it up-to-date. |
Agreed. My thinking is that Lite+ only has a place in the world right now because we don't yet feel comfortable pushing the newer codebase (and more stringent requirements, like Opcache instead of APC and PHP 5.4+) to the existing Lite userbase. Once we see that enough users are running PHP 5.4+, I would be fine with merging Lite+ into Lite and getting rid of Lite+ altogether (or keeping Lite+ with some additional benefits). The point being, I don't see us maintaining two separate codebases for more than 6-12 months. However, in the interim we do need to manage the shortcomings of the old codebase in a way that doesn't hurt the image of ZenCache overall (i.e., Lite, Lite+, and Pro).
Right, agreed. So what do you think we should do about the bugs/limitations of the old codebase (namely Multisite support)? I wouldn't feel comfortable stripping Multisite support out altogether, although that feels like the right thing to do. There are way too many people already using ZenCache Lite on multisite (even though it's broken in various ways, depending on your multisite configuration) and just outright removing that functionality seems a bit drastic. I feel our best option with regards to multisite in the Lite version is the following:
We'd allow users to continue using Lite on Multisite as-is, but if someone complains about a bug, we'd just point them to Lite+ and say that Multisite is only fully supported with Lite+. |
|
Wrote changelog entries for all work in this PR:
|
Agree. That sounds great to me :-) |
I suggest linking this to the page for that plugin to help clarify that compatibility is with that specific domain mapping plugin. There is more than one out there, so it might help to avoid confusion while we work to make ZC compatible with others in the future. |
Copy. Will do. |
I reviewed the rest of that. Looks fantastic! |
Resolves & Includes