bamajr

I have added a support request to WordPress SEO, here:

https://www.ads-software.com/support/topic/complete-stoppage-of-redirection-1

In case anyone is interested in seeing what their developers have to say.

Ron,

The issue does seem to somehow involve the WordPress SEO Plugin, though in the looking I’ve done, I can’t figure out why it behaves this way.

I also know to turn to the developers of the updating plugin, if that is when the issue occurs. In this specific instance, it occurs each and every time, the WordPress SEO Plugin, has an available update. So, naturally, Joost de Valk and his team would be the first place to turn. I know the WordPress SEO Plugin is not immune to coding errors and they do a pretty decent job of fixing issues, as they arise. I just have a hard time believing that the issue lies solely on WordPress SEO.

Someone needs to quit changing the status of this issue to “RESOLVED”

This issue is NOT resolved and very annoying. It is so annoying, I’m trying to decide which of the two plugins, to quit using. You two plugin developers need to get together and get this issue fixed.

This issue occurs each and EVERY time a WordPress SEO Update is made available. Not when it is applied, but when it is made available. To rid the problem, one must apply the update to WordPress SEO, then deactivate/reactivate it.

It is very obvious that the one or the other plugin, is trampling on the code of the other.

This issue occurs every time a WordPress SEO Update is made available. Not when it is applied, but when it is made available. To rid the problem, one must apply the update to WordPress SEO, then deactivate/reactivate it.

I’ll be glad when this is no longer an issue. It is frustrating and it eliminates the appeal of this plugin and at least one Genesis Theme.

Upon further testing, the issue seems to have been caused by the latest update to the WordPress SEO Plugin, by Joost de Valk. I’m not sure as to what caused the issue, but I can tell you that it seems to go away, by deactivating the WordPress SEO plugin and then re-activating it.

I know StudioPress/Genesis works with WordPress SEO, but this specific plugin combination seems to trigger a unique bug… worth looking in to.

@scottareed

Posts to Facebook wil go exactly to the Page/Profile you set them to go. In my case, the URL for the Community Page was incorrectly configured in this plugin’s “Your Facebook URL” setting. If that is where a person wanted the posts to go, it does work.

However, when I changed the “Your Facebook URL” setting, to reflect the correct URL the NextScripts Plugin began posting to my Facebook Profile, as I had originally intended.

This mix up in configuration, seems to be an issue, I caused, not the NextScripts Plugin.

Ok…

I did answer my own question, but can’t explain how it happened.

Under the Facebook Settings, the “Your Facebook URL” was incorrect. It needed to be and it was which is weird.

Originally, I had the correct URL because when I did the test post, it worked correctly, once. Then somehow it got switched. I don’t remember changing it, but I must have, right?

I think I may have answered my own question… I’ll report back on this soon.

Thanks David…

As I started this discussion on the StudioPress website, I’ll chime in with a “Plus 1” for getting this fixed.

I also posted a suggestion, specific to this issue (https://www.studiopress.com/forums/topic/genesis-responsive-slider-order-does-not-work/#post-14140), suggesting that the order be defined as a list of page/post IDs, separated by commas, similar to the way one can include/exclude pages/posts by ID. This way, I can define that IDs 1, 11, 19, 43, & 77 be displayed as:

1, 11, 19, 43, 77

or…

77, 43, 19, 11, 1

or…

19, 1, 43, 77, 11

Does this make sense?

@kurt Payne…

Thanks for your response. As a custom plugin developer, I fully understand what “Must Use” plugins are and why plugins may, or may not have that designation. Based on your answer, I’ll change my “Broken” designation to “Works” instead, but your answer brings up other questions.

1. Why aren’t MU Plugins counted in the “ALL” plugins total, by the WordPress core? I know this is probably more of a WordPress Core question, but I thought I’d bring it up here first, since it seems like it should be directly related.

2. Why doesn’t the P3 Profile the MU Plugin, separately from the general plugin? If P3 is going to identify an additional MU Plugin, it should profile the MU plugin, separate from the main plugin, don’t you think. In other words: If Akismet and P3 are the only plugins installed/active and P3 insists I have 3 plugins installed, why doesn’t the P3 profiler, identify the MU Plugin separately, in reporting its statistics?

Oh, side note (FYI): I was very careful to select the current version of WordPress, when I submitted this post. Yet, looking at the right column, the WordPress version is INCORRECTLY identified as 3.3.1 when I chose, 3.5

@clifford Paulick

For the most part, the previous posts were, on point, though I can see how it may look like we went off on a tangent.

The intent of my original post was definitely to find a way to use VideoPress without WordPress or VideoPress branding. However, I am looking for an “Un-branded VideoPress” which can be utilized, directly from within Self-hosted (www.ads-software.com) websites, instead of embedding a video from the VideoPress servers. I want the video to reside on the same server as my website.

So, while I did post the original post, on this topic, this is why my follow-up posts, seemed to take a little different direction.

@jeremy Herve

Thanks for the reply and I’m fully aware of all the information you shared. My point is that VideoPress doesn’t offer anything, that I can see, as a distinguishable difference to that of YouTube, Ustream, Vimeo or the numerous other Video Hosting Services…

…and, if VideoPress, doesn’t also allow you to host your own Video, on your own WordPress installation, why use VideoPress instead of YouTube, Ustream, Vimeo or any of the other Video Hosting Services?

I’m going to try to bring this thread back to the original topic…

@jeremy Herve

VideoPress is a “hosted service” which stays within the confines of WordPress.com

I’m suggesting, that there should be a VideoPress equivalent for those people who don’t what to host their Videos within the confines of WordPress.com

If I’m hosting my own WordPress (www.ads-software.com) installation, or if I’m paying for hosting on GoDaddy or some other web host, why would I want to host my videos on WordPress.com instead of within my own installation?

I guess ultimately, VideoPress equates to a paid option, similar to that of YouTube, Ustream or Vimeo – all of which, I’d never pay for, cause they ain’t worth it. Why not just upload my own videos, compressed and ready for HTML5 playback?

@josh Lyford,

Okay… I’m not sure of the exact sql query, but things seem to be working as expected now. Below, I noted what I did, on which website.

1. https://bamajr.com
   I never uninstalled the plugin, for this website. As mentioned earlier in this thread, I was presented with an error page, every time I tried to uninstall SendPress. On this website, I had left SendPress installed, but deactivated. I ran the update to 0.8.8.1 and reactivated the plugin. When I tested for the issues described above, I am happy to report, the 500 Internal Server Error was no longer occurring.

   I also went through the process of deactivating the SendPress and trying to uninstall it again. This time, the uninstall went through without a hitch. I re-installed SendPress and, again, and activated it, at the end of the installation process. I tested for the issues, reported above. Everything seems to be running perfectly.

2. https://alabamacoolingandheating.com
   I had uninstalled SendPress from this website. The uninstall, for some reason, didn’t present me with the same error, on this website as it did for https://bamajr.com

   I re-installed SendPress 0.8.8.1 from the www.ads-software.com repository and activated it, at the end of the installation process. Again, I tested for the issues, reported above and everything seems to be working correctly now.

Conclusion: what ever SQL Query you found, must have been causing these issues, as I could easily duplicate the described problems, prior to the update to v. 0.8.8.1

CUDOS to you and/or your development team! ??

On a side note…

Were you ever able to locate or identify the “sizable overhead” issue in the SendPress Tables, as described, above, by @carlytx ?

P.S. Josh, look for an email from me today… You’ll recognize the “Bamajr” in my email address ??