I'm sorry Phil,
I can only repeat what I answered William Shoap 3 days ago on the Contact Suggestions page:

I'm just trying to support Ossn here and there in my free time. I
enjoy it - no question - but I don't want it to become an obligation
in my private life. And that's why I'm not available for 'offline'
talk, any kind of paid work or what so ever.

But I'm thinking of adding a separate file you may put your 3rd party stuff into in a 1:1 way with the next GreenByGreen release. In case I get it working, it will become part of the new GbG backup mechanism and is guaranteed to be untouched by future theme updates.

Phil, First of all This community is more developers centric but General questions are welcome!

Another thought... this shouldn't even be on a theme level. it SHOULD be on an OSSN level so the scripts are available within ANY theme currently being used.

There is no way for me to add millions of scripts in OSSN if that what you meant by this be part of OSSN level not theme level.

Anyway... IF a method can be developed for the future, fine. If not.

There is already a method, Phil,

The way OSSN is designed to give flexibility to developers they can structure the layout as per their need without thouching the OSSN and it make sense to add themes stuff inside theme.

If you don't want to touch theme then there is a other way called component, (I know that you are not a developer but the code is for developers) Well that is very simple to add your script / custom script via component. That is what Hello world component teaches. (https://github.com/opensource-socialnetwork/HelloWorld/blob/master/ossn_com.php#L42)

Regarding GreenByGreen theme as this is custom theme not a core package, developer can change anything inside theme and if you modified the theme that mean you have adopted the theme and you are on your own, then you need to worry about it if you wish to use future upgrades and new features added inside it. If you don't then you don't need to worry about it, but you can't complain if developer changes the files in next update.

OSSN is similar to Wordpress, Joomla and this is how they are running. Below is a OSSN code that you can use in your OSSN component will add a custom script in head.

function my_custom_script_init(){
    ossn_new_external_js('myscript.js', 'https://website.com/myscript.js', false);
    ossn_load_external_js('myscript.js');
}       
ossn_register_callback('ossn', 'init', 'my_custom_script_init');

This code is copied from WordPress documentation a nd you can see it is almost similar to OSSN

function my_scripts() {
    wp_register_script( 'custom-script', 'https://mywebsite.com/js/custom-script.js' );
    wp_enqueue_script( 'custom-script' );
}
add_action( 'wp_enqueue_scripts', 'my_scripts' );

.

Another thought... this shouldn't even be on a theme level. it SHOULD be on an OSSN level so the scripts are available within ANY theme currently being used.

Sorry... I drifted on the last paragraph... that was in reference to GxG.

The homelancer component does not work in all cases for this. Out of three scripts I needed to put in, only one was inserted properly. And that is inserting the script EXACTLY the way it was provided by the advertising company, just without the tags!!! Where I find the problem to likely be with that component is it calls for you to insert the script WITHOUT the <script> and </script> tags (which, I actually mentioned in this thread earlier on... and don't know WHY for the life of me it would want you to put a script in other than in the way the script was made by the author of it, who designed it to work how their company needs it to)... causes errors like it did with the two that didn't work, so I'd say it's a BUG in the component. So... NOT wrong.

There should be a method for keeping things webmasters NEED for their systems to function the way they need to. Very few people are trying to run on expensive servers for free, and a few direct link ads thought the ads component are in no way going to support an even half way serious venture.

I'm not trying to be overly difficult here, just pointing out the obvious. and as I said earlier, I have seen many people have pointed out the obvious on many things in other posts. Often with the same kind of response I'm getting which makes me feel like a lot of people just think we all do this for a hobby or something.

Anyway... IF a method can be developed for the future, fine. If not... I'll just have to pay close attention in the future and do upgrades one component at a time, re-applying my changes one at a time, tediously, because I can no longer operate without modifying certain "so called" core items. So... cool... whatever.

With all that said... is there any way I might PAY you for applying some changes for me to the last version (not the 2.x newer one)? I would really like those changes, but I have no time to go through re-applying all the changes I made to color scheme with the new editor for a while and the other modifications I made to CSS. I would pay even just for the modified files other than the editor and instructions on how to apply them to my current theme. Let me know.

in this case, it would be in the page.php of green by green)... and NEVER have to worry about it again, unless the advertiser provided a different script.

Simply wrong. You'll ALWAYS have to worry about it again. Because the next release of GreenByGreen comes with another page.php for sure - and you'll have to merge your additions back in again.
That's why the recommended way is using a component instead - in this case Homelancer's Custom CSS/JS

First of all, I did not understand, at all, what you meant with that incoherence. My idea of "normal", in the case of this post, would be that I would put the needed script in where it needs to be... in this case, it would be in the page.php of green by green)... and NEVER have to worry about it again, unless the advertiser provided a different script. That would be "normal". You see, they work with "industry STANDARDS"... keyword being "standard"... standard being a synonym of "normal". If you work OUTSIDE of industry standards, you are not working with something "normal". That is my understanding of the "normal" world.

Now... I do like OSSN, love the customization, am doing QUITE well with it and my customization with a daily growing userbase that is now starting to show exponential growth, (so I must be doing something right and know a bit of what the heck I'm talking about) so please don't try to imply there is something wrong with MY concerns on many of these things or understanding of them. Reading back through all the messages on here it is obvious that it is a very common thing, and NOT unique to me AT ALL. Now, with that said, I really wish I would get some decent, cooperative, answers when I ask something (like maybe an answer to my unanswered question on member avatars for days now) that makes my use of this package effective. After all... my understanding is that this is a support forum for OSSN, not a developers forum, correct?

I'm going to "try" and not be frustrated that everything has to be a NIGHTMARE to implement with this because it just can't be done in the "normal" way...

Yes, because your idea of ​​"normal" code is that there is ONE single index.php monolyte that contains everything. So you would know out of a moment to simply add that extra stuff at line #3,897,166 - and that's it.

Thank you for the feedback. Was aware of page.php. A component required to prevent important settings by webmasters to not be overwritten is pretty flaky, though... in my opinion. Important OSSN stuff should be contained in a configuration file, rather than where webmasters have to implement things for their requirements. That's just -my- opinion, though. I guess I have to just do what I have to do. Thanks again for the response, though.

This is the file where you can take a look : https://github.com/opensource-socialnetwork/opensource-socialnetwork/blob/v5.x/themes/goblue/plugins/default/theme/page/page.php If you don't wanted to override during upgrade then a component required to be written.