It is a little questionable that this script isn't using jQuery's site directly instead of the current at https://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.11.1.min.js

You also have this issue on your other published script.

It is a little questionable that this script isn't using jQuery's site directly instead of the current at https://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.11.1.min.js

You also have this issue on a few other scripts as well.

It is recommended to utilize the @license key in your UserScript metadata block and also you need to point it to the correct GH url at https://raw.githubusercontent.com/HodofHod/Userscripts/master/LICENSE instead of https://raw2.github.com/HodofHod/Userscripts/master/LICENSE

Thanks.

Re: @yasingedik:

... did not work either ...

Found a reason for SeaMonkey and Firefox that it won't work... because some of your CSS rules don't have a closing } on a few lines. e.g. the CSS is being dropped due to syntax errors in the styling. Try the fork I did in TamperMonkey and let me know how it goes for you. Thanks. :)

Re: @yasingedik:

... did not work either...

Now you've really peaked my curiosity here...

• First off do you have a public link to a page where this script is supposed to make a large visible alteration so I can see what kind of style you are applying? e.g. not just http://reader.aol.com/
• Secondly... for grins I did a temporary fork of your project here to test in TamperMonkey versus your individual ones in this one.

Let me know at your earliest convenience for the above.

Nothing to see just testing issue creation on production.

Re: @yasingedik:

I would be glad if you can point me to a resource to learn how to fix that.

It should be supported in JavaScript and the Array method of join is also base JavaScript so shouldn't need to be dependent upon Tampermonkey. shrugs

You might try the line continuation character of \ instead of these functions too if there is some issue in those browsers not supporting standard JavaScript methods:

GM_addStyle("\
  .header-search-wrap { margin-top: 0px !important;}\
  .dropdown-menu-add .page-container {height: 498px !important;}",\
  .dropdown-menu-add {height: 500px !important; left: -50px !important; max-height: 500px !important;}\
"})();

This is not as pretty and readable I think but will also simplify the DOM a bit since GM_addStyle can create style tags at every use... if you find a way to put it as one big string then utilize that GM API once you'll be speeding up the page a bit. :) Thanks for the consideration.

This script is "unlicensed" which doesn't fall within the Terms of Service here on OUJS.

Please correct soon or it will be removed.

Re: @Ede_123:

It's pulling the meta.js from https://openuserjs.org/install/Ede_123/OpenSubtitles_Direct_Downloads.meta.js

Have you actually tried clicking that link directly? GM and other engines will use that and it 404's because you didn't use the OUJS form, which for this script is:

https://openuserjs.org/meta/Ede_123/OpenSubtitles_Direct_Downloads.meta.js

Some of the engines fallback on error to the install path, in OUJS case that would be https://openuserjs.org/install/Ede_123/OpenSubtitles_Direct_Downloads.user.js ... so you aren't using the update mechanism in some engines and making your users use full source instead of meta.js... thus you are breaking the update mechanism. Not to mention if the engine isn't smart enough to store the failure and never request it again... e.g. generating more traffic than may be necessary. On any engine that doesn't support the request header, e.g. older GM versions for example, you are sending out a request that fails to update.

All of this is usually why it's recommended to let the engine handle it to avoid confusion. Consolidation is okay and a feature available but if you want OUJS to handle it for GH installs... then you need to use the proper route (path) to the meta.js routine. :) Does this all make more sense now?

Re: @Ede_123:

strips @updateURL and @downloadURL for uploaded scripts

Different and questionable methodology that OUJS doesn't support nor any of the known .user.js engines. OUJS attempts to offer the same choices that the engines do instead of no choice.

I had hoped updates would automatically be pulled from OUJS?

If you want to force update checks, or consolidate, from OUJS (or another site) you can specify it manually. The .user.js engines default from whatever site it is installed from, which that methodology is demonstrated at oujs - Meta View, and that breadcrumb trail leads to #105 (comment) for the manual route (a.k.a the @updateURL).

GitHub where no meta.js is available

Some authors create one manually or with script processing before committing to GH to make one.

The choice is yours on how to handle this correctly. Just thought I'd pipe in that I saw you were assuming USO standards not OUJS... and breaking updates with all .user.js engines that support updating e.g. your users won't get updates on a url that returns 404 from us. :)

You appear to have this issue on multiple scripts as well.

While we at OUJS do have meta.js your implementation is incorrect. Modern .user.js managers already support these automatically so technically they can be omitted.

Target code:

// @updateURL   https://openuserjs.org/install/Ede_123/OpenSubtitles_Direct_Downloads.meta.js

Thanks.

This script is "unlicensed" which doesn't fall within the Terms of Service here on OUJS.

Please correct soon or it will be removed.

You've been warned multiple times on this before. Termination of this script is in effect.

Re: @decembre:

No news.

This has an official home issue now at #601

Re: @decembre:

Never say never. ;) :) Eventually that feature will be on dev and trickle down... until then... one should think thoroughly before tapping the reply button. :) This also needs to be focused on GH issue tracker. Thanks.

Re: @decembre:

#461

Patience... the button/link is going away but with any luck a replacement will be ready hopefully in a few weeks or perhaps less... and I know you know this already. :P :)

This should be the end of the discussion here as it needs to be done on development under a GH issue to keep things focused. Thanks.

Nice addition.

Re: @devnoname120:

Because your account isn't the same here on OUJS as GH this won't auto-sync because you don't own the script under this username.

You will need to manually upload or paste your changes in if you keep it under your @devnoname120 to change the content stored here on OUJS... client/user side GM, or other, will pull from @HandyScripts on GH... however the OUJS source will not because that's not your account here on OUJS.

Seems that your external script host requires validation through google and we're not privy to that... this is the ultimate obfuscation and isn't permitted. Your script will be removed along with your account.

This site is for valid open-source projects not hidden. Bye

Does anyone realize that google has identified this script as potentially harmful and is occasionally preventing loading from it's referenced external source right? The obfuscation present on the external script raises an eyebrow here.

Unfortunately the problem is already here... your current implementation of your script covers up linkage already on small viewports. Nice for full width devices though. When affecting the base code decisions should be based on the whole experience not just one. :)