prometheangroup

Okay… We figured out a workaround… Your plugin argument still doesn’t appear to be functioning, but we can manually sort the output by specifying the “order” of each page on the same level of a hierarchy using the QuickEdit feature on the backend CMS… You still may want to look into why this sort_column paramater seems to be non-functioning.

We have the latest version of your plugin… The sort_column parameter of your shortcode is not working… There is no change to the sorting of the list regardless of what we put in for menu_order… we are just using [pagelist sort_column=”menu_order”]. Are you aware of this bug?

Okay, we traced the issue to residuals that needed cleaned up in the wp-content/cache folder. So we resolved the second problem of caching, even while logged in, by simply removing the plugin, wiping out the wp-content/cache folder’s contents, and re-installing the plugin.

However, we STILL cannot get your plugin to load the cached version of the homepage.

Any prograss, or… What are your ideas on how to fix this?

This is urgent enough that we can’t wait on you to publish a fix. Can you give us a hint as to how you are doing the conditional check on whether the user is logged in or not?

Where does that occur in your plugin? (.htaccess, wp-load, etc.)?

Any preliminary hints or clues would be greatly appreciated as we need this fixed ASAP and are willing to do a hack / patch ourselves in the mean time while you work on a larger fix.

Thanks,

[Moderator Note: No bumping. If it’s that urgent after waiting just 5 minutes, consider hiring someone instead.]

Actually, now we’ve got a major bug… We’ve got the plugin configured to NOT show cached pages for logged in users, however, most of the time, it still shows the cached pages. This is a problem because it doesn’t show the user as logged in and this prevents them from commenting as their user account.

So basically, it is showing caching pages almost all of the time, regardless of whether you are logged in or not. We need for the pages to dynamically load if the user is logged in.

Is this a bug or is there something we can do to fix this immediately?

URGENT.

Thanks,

Yes, we tried all of the standard tricks both in dev and test, (test is an exact hw/sw replica of production), as is SOP for any CMS issue logged.

We certainly can sympathize with your desire to rename this (whatever you are wanting to call it) something more politically correct, other than a “bug.” It appears your definition of a bug is more narrow than ours, and we should probably adopt your “softer” stance on “name-calling” of these topics (avoiding the dreaded “B” word) as these gracious plug-in developers are largely unpaid and exceedingly under-appreciated.

Suffice it to say, we greatly appreciate both the plug-in developers and anyone who positively contributes to any of the related forums. And of course, we are a consistent monetary donator to many of the contributors to this as well as various other open-source communities.

So to get any future forum-good-samaritans more up to speed on where we are, and avoid suggesting already tried stuff, we believe we’ve narrowed it down to a database residuals issue from legacy plugins that have somehow created “stealth-conflicts” in migrating to 3.8.1. This is due to the fact that this site has a fairly lengthy history and countless plugins were installed and then uninstalled, but as you know, can unfortunately leave residual data in mySQL.

We’re probably going to stop debugging (oops! I mean de-investigating) this topic because we were able to just reverse-engineer the working plugin code in the CMS console that does essentially the same thing and write our own [shortcode].

Nonetheless, if we do happen to find the issue and related patch / fix on another one of our WP instances, we’ll post the solution here for posterity.

Thanks!

We are seeing exactly the same bug as above. we have cleared out transients. Still getting the “using transient” bug with no top content data. We have uninstalled the plugin and we have even reverted back to the 1.4.8 version of the plugin. Still the same bug exists, providing no data, just the “using transient” bug.

We have tried numerous different fixes, including the exact example shortcode on the plugin page with the same results and yes, all of our posts have more far more than 5 views. Also, please note that this plugin was working great before the 3.8.1 upgrade.

Also strange is that the daskboard top-content widget is working fine, so that leads us to believe it is just a simple bug in the shortcode that is not compatible with WordPress 3.8.1.

What is the status of getting this shortcodes bug fixed?

Appreciate your help and will gladly contribute a donation, if you can get this fixed in a timely fashion… Yes, that is a bribe.

FOLLOW-UP:

Okay, we found a solution, not ideal, but apparently, this plugin is not compatible with sites that don’t have the root folder secured with SSL and do have a sub-page secured with SSL… Or at least, that’s what it appears to be the case. (Appears to work fine for sites with no SSL)

At any rate, we fixed the multiple redirects by simply making the whole site https. Like I said, not an idea solution because of about 2/10th of a second of SSL latency, but a trade-off by having cached pages load 3x faster.

I’m surprised this hasn’t come up with other users.

A specific fix for this issue would be greatly appreciated… Namely, enhancements to the .htaccess mods so it doesn’t do the redirects and drop the $_POST data when using a site that is partially secured with https (SSL).

Thus, I’d like to keep this thread open until either a response or fix is offered.

Sorry about the typo… “Aron” is meant to be “Rob”… iPhone auto-correct strikes again!!!

Okay… I’ve done some more digging into how Rob designed the plugin… And now I see why he’s having trouble fixing this bug… First if all, it is definitely a bug… But it is not Aron’s bug… It is a Google bug… It appears that for the free. Version, Rob is pulling code from Google to not only render the selector drop down, but also to fire off functions… So Rob may simply not have access to modify those functions… Which is probably why he takes full control of the plugin code in the paid version… I have tested both the free and paid versions… The free version 2.7 does exhibit the bug, and should be pulled down, IMHO… The 2.8 paid version seems to be working fine, and for $12 probably won’t break the bank… In summary, the paid version is a great plugin… Great job, Rob… The free version, not so much.

FYI for the community… Although we always appreciate highly responsive and active plugin authors, such as Rob… This topic is definitely not resolved. A couple of fundamental problems with the plugin are that if the user wants the respective site in the default language, processing the GLT code is tremendous overhead and latency when no processing is needed. And second, it just a matter of semantics, but IMHO, most developers would consider the concept of “re-translating” the default language a major bug in the plugin. I understand Rob’s point that the “default language” could potentially be a slightly different concept than the native language in the WordPress database content, but that is such a stupendously microscopic case, it’s simply poor logic. I see both points, but in the end, I would vote to design the plugin for maximum usability with the vast majority of installations, instead of fiercely sticking to a philosophical point, which could be valid… SUMMARY: Please simply provide a checkbox option to DISABLE GLT if the default language is chosen.