seandfeeney
Forum Replies Created
-
Just installed V2.0.40 – 11.26.2013 saw the line “Fixed: Sub-album requests conflicting with paginated galleries on the same page” in the change log.
You guys rock! Issue is resolved!
Is there a proper way to refresh / reinstall without losing your gallery data?
@photocrati – I just tested it with twenty twelve and the issue continues to exist. If you are interested in trying it out and seeing for yourself, check out http://rjmartinknives.com/category/knives/current/
Please ignore the post Q-36 Flipper Folder because I resolved that with the redirection plugin. I don’t want to apply a 301 redirect for every single pagination link if I don’t have to.
I should add, when I set this up over a year ago (probably closer to two years ago) I didn’t have this problem.
Not that I see but, I will keep an eye on it.
After many reloads and rebuilds (about 5) it finally shows 100%. I will see how this workaround goes, long-term. Thanks!
I do have w3 cache enabled with minify disabled. It does work on some posts but, on the ones that doesn’t work, there are no related posts on the edit post page.
Example… http://wp.me/p14H51-9a
I have it set to 1…
This beta didn’t work for me. Still seeing posts without any related posts. If I could make a suggestion, could you add a button to select random posts if it can’t find any that are related?
I figured out that the more display issue was actually caused by w3 total cache’s minify option. Setting it from auto to manual caused many issues I was experiencing to go away (see dynamic to the top display issue here).
I will have to remain more conscious of this issue. Thanks for your help and support!
More specifically, disabling minify allows this to display
I had a hunch and was right. It is conflicting with w3 total cache. Hopefully, this can get resolved without having to disable one or the other…
I have a site which is getting much traffic regularly. Going around and disabling plugins isn’t really an option.
It looks more like a CSS display problem. The code is there via the inspector but, when you hover it doesn’t trigger
div.sharedaddy .sharing-hidden .inner:hoverIn order to get this to display, I had to force a larger height of 105px to
div.sharedaddy .sd-contentand click on the :hover check box in chromes inspector.This does work in the live preview area however.
1.6.1 “fixes” the via problem but, I hate to be the cynical “that guy” but, using the URL as a means of generating a twitter handle automatically is a terrible solution. The sharing page has plenty of space to allow users to enter their twitter handle they would like to use. I actually like the via option and I am left with this band-aid solution.
Also, there are many issues with the whole sharing portion of this release. Hovering over “more” doesn’t do anything and clicking on it just jumps to the top of the page.
Speaking as someone with a project management background, you may just want to back out of the recent changes to sharing and go back and make it work right before releasing another fix. Releasing many incremental fixes back to back just doesn’t look good for jetpack and I am already researching potential other solutions.
Sorry for the rant.