I asked copilot:

I need you to help me understand the RPS plugin/themes better as I am having function and styling issues trying to use the RSP plugin with non-rsp themes.

I need you to be as succinct with your responses as possible.

If you look at any RSP theme’s functions.php file, you see
    wp_enqueue_script("quovolver", get_bloginfo('template_url').'/js/jquery.quovolver.js');
    wp_enqueue_script("flowplayer", get_bloginfo('template_url').'/js/flowplayer-3.2.6.min.js');  
    wp_enqueue_script('colorbox', get_bloginfo('template_url').'/js/jquery.colorbox-min.js');
    wp_enqueue_script('modernizr', get_bloginfo('template_url').'/js/modernizr-1.7.min.js');
    wp_enqueue_script('modernizr_webp', get_bloginfo('template_url').'/js/modernizr-custom.js');
    wp_enqueue_script('st-tabs', get_bloginfo('template_url').'/js/init.js');
    wp_enqueue_script('wrap-table', get_bloginfo('template_url').'/js/wrap-table.js');  
    wp_enqueue_script('mobile-menu', get_bloginfo('template_url').'/js/mobile-menu.js');
    // css files
    wp_enqueue_style("jquery-ui-theme", get_bloginfo('template_url').'/css/style.jquery-ui.css');
(I realize some of these are actually not needed if not using an RSP theme, but let’ snot dwell on that).

These are easy enough to understand. Each of the CSS and JS files are located in folders.

/wp-content/themes/[rsp theme]/css

/wp-content/themes/[rsp theme]/js

The issue I am having is styling and function of the order form. You see in functions.php, you see this…
wp_enqueue_script("order-form-msg", get_permalink(get_option('rp_order_form')).'js/ui.achtung-min.js');
wp_enqueue_script("order-form-common", get_permalink(get_option('rp_order_form')).'js/common.js');
wp_enqueue_style("order-form", get_permalink(get_option('rp_order_form')).'css/style.css');
wp_enqueue_style("order-form-achtung", get_permalink(get_option('rp_order_form')).'css/ui.achtung.css');
(notice that the path to each file does not begin with “/”)

Looks easy enough, except it’s not.

You see, if you look at page source for order form, you would see that it appears these files are located at…
<link rel='stylesheet' id='order-form-css' href='https://vamohost.com/order-form/css/style.css?ver=6.9' type='text/css' media='all' />
<link rel='stylesheet' id='order-form-achtung-css' href='https://vamohost.com/order-form/css/ui.achtung.css?ver=6.9' type='text/css' media='all' />
<script type="text/javascript" src="https://vamohost.com/order-form/js/ui.achtung-min.js?ver=6.9" id="order-form-msg-js"></script>
<script type="text/javascript" src="https://vamohost.com/order-form/js/common.js?ver=6.9" id="order-form-common-js"></script>
…leading you to believe that these 4 CSS and JS files are located in `/wp-content/themes/[rsp theme]/order-form/js` and /wp-content/themes/[rsp theme]/order-form/css`. However subdirectory `/order-form/` doesn’t exist (I’ve known this for years but never had a reason to investigate).

I also checked the RSP plugin, and cannot find these files.

I also check the database for various string found in those files when you view them in “view source” in a browser, but found nothing.

Now, last thing: if you look at .htaccess file, you see the following:

`RewriteRule order-form/(.+\.(css|js|gif|png|webp|jp?g|php))$ /wp-content/plugins/resellerspanel/lib/rp_proxy.php?store_name=vamonet&uri=$1&redirect_params=%{QUERY_STRING} [L]`

If can override any CSS rule for the order form by putting it in my theme’s CSS but I want a deeper understand of what’s going on here.

Can you help me figure out why/how these particular order form JS and CSS are not located in my website’s theme or RSP plugin files and how this all works even though they are not located in my theme’s files or the plugin’s file?

Please try not to assume anything and please ask me questions if needed.

Copilot’s response:

Here’s the succinct, mechanically‑accurate explanation of what’s happening.
No assumptions, no fluff — just the architecture.

⭐ The short answer

Those order‑form CSS/JS files do not live in your theme
and do not live in the RSP plugin
because they are not local files at all.

They are remote files served by ResellersPanel’s servers, and your .htaccess rule is proxy‑mapping the URLs so they look like local files.

Everything you’re seeing is the result of URL rewriting + a PHP proxy.

⭐ The key mechanism: the `.htaccess` rewrite rule

You already found the smoking gun:

RewriteRule order-form/(.+\.(css|js|gif|png|webp|jp?g|php))$ \
/wp-content/plugins/resellerspanel/lib/rp_proxy.php?store_name=vamonet&uri=$1&redirect_params=%{QUERY_STRING} [L]

This means:

✔ Any request to

https://yourdomain.com/order-form/...

is NOT served from your filesystem.

✔ Instead, Apache rewrites it to

/wp-content/plugins/resellerspanel/lib/rp_proxy.php

✔ That PHP file fetches the real file from ResellersPanel’s servers

and streams it back to the browser.

So the files appear to be local, but they are actually remote assets.

⭐ Why the paths in functions.php look like this:

get_permalink(get_option('rp_order_form')).'js/common.js'

get_permalink(get_option('rp_order_form')) returns:

https://yourdomain.com/order-form/

So the final URL becomes:

https://yourdomain.com/order-form/js/common.js

But again — that folder does not exist.

The URL is intercepted by .htaccess and routed to the proxy.

⭐ Where the real files actually live

They live on ResellersPanel’s infrastructure, not on your server.

The proxy script (rp_proxy.php) fetches them from something like:

https://supersite.resellerspanel.com/.../order-form/js/common.js

(Exact URL varies per reseller account.) ***(MY NOTE: THE BEGINNING URL STRUCTURE IS INCORRECT BUT THE PRINCIPLE IS SOUND).***

You never see the real URL because the proxy hides it.

⭐ Why RSP does this

They control the order form logic centrally
So they can update it without pushing updates to your site.
They avoid exposing their internal file structure
Everything is funneled through the proxy.
They ensure the order form always matches their backend
Pricing logic, validation, domain search, etc.
They prevent resellers from breaking the order form
By not letting you modify the JS directly.

⭐ Why you can override CSS but not JS

CSS is loaded after the remote CSS → you can override it.
JS is executed from the remote source → you cannot override or modify it.

This is intentional.

⭐ Why you couldn’t find the files in your theme or plugin

Because they aren’t there.

They are:

not in your theme
not in the RSP plugin
not in your uploads
not in your database

They are remote, fetched through rp_proxy.php.

⭐ How the whole system works (succinct)

RSP theme enqueues URLs like:
https://yourdomain.com/order-form/js/common.js
Apache sees /order-form/...
and rewrites it to rp_proxy.php.
rp_proxy.php fetches the real file from RSP’s servers.
The browser receives the file as if it were local.
You can override CSS locally, but JS is locked down.

⭐ If you want, I can explain:

how to safely override order form CSS
how to isolate order form styling from your theme
how to debug order form JS issues
how to load the order form assets in non‑RSP themes
how to avoid conflicts with Blocksy or other modern themes

Just tell me which direction you want to go.

——————–

I said:

OK, this is what I suspected and it explains why it takes every site that use the RSP API plugin around 5-7 seconds for the order form to load in. This is why some sites direct their buttons to the order form of their “Store Master Theme” because it loads in nearly instantly. The downside is that you have to control over the order form CSS that way.

So that brings me to another question. Since the CSS of the order form is located remotely on RSP’s servers, how is it that I am able to override any part of the order form’s CSS simply by using the theme’s CSS? (I know this is true because I have done It many times. As long as you know the CSS rule in the remote order form CSS, you can just place it in your theme’s CSS and modify it and that overrides the rule in remote CSS.)

You’re exactly right about the load‑time issue, and you’ve now uncovered the other half of the architecture:
even though the order‑form CSS is remote, it is still fully override‑able by your theme.

And the reason is simple, mechanical, and 100% predictable once you see how the browser handles CSS.

Let’s break it down cleanly.

⭐ Why you can override remote CSS with your theme’s CSS

Even though the order‑form CSS is served remotely through the proxy, the browser doesn’t care where a stylesheet comes from.

The browser only cares about:

1. Load order

2. Selector specificity

3. `!important` flags

That’s it.

There is nothing special about remote CSS.
Once it reaches the browser, it behaves exactly like any other stylesheet.

⭐ What actually happens in the browser

1. RSP’s remote CSS loads first

Because the theme enqueues it early:

<link rel='stylesheet' id='order-form-css' href='https://yourdomain.com/order-form/css/style.css' />

2. Your theme’s CSS loads later

WordPress always loads theme stylesheets after plugin/theme‑injected styles unless explicitly reordered.

So your theme’s stylesheet appears below the remote CSS in the <head>.

3. Later styles override earlier styles

This is standard CSS cascade behavior.

So if RSP has:

.order-form-button { background: #0099cc; }

And your theme has:

.order-form-button { background: #ff0000; }

Your rule wins because it appears later.

⭐ Why this works even though the CSS is remote

Because once the remote CSS is fetched and parsed, it becomes part of the same cascade as everything else.

The browser does not treat remote CSS differently.
It does not lock it.
It does not sandbox it.
It does not protect it.

It’s just another stylesheet.

⭐ Why you can override everything except JS

CSS is passive.
It’s just rules.

JS is active.
It executes logic.

RSP intentionally locks down the JS by:

serving it remotely
proxying it
not exposing hooks
not exposing filters
not allowing overrides

But CSS is not locked down because:

they expect resellers to customize colors
they expect resellers to brand their sites
CSS overrides don’t break backend logic
CSS overrides don’t affect pricing or validation

So overriding CSS is safe.
Overriding JS is not.

⭐ Why the “Store Master Theme” order form loads instantly

Because:

it loads the order form directly from RSP’s servers
it doesn’t proxy through your site
it doesn’t wait for WordPress to initialize
it doesn’t wait for your theme
it doesn’t wait for plugin hooks
it doesn’t wait for the proxy script

Your site → proxy → RSP → back to browser
is always slower than
RSP → browser.

But the tradeoff is exactly what you said:

fast load
zero control over CSS

⭐ Bottom line

You can override the remote CSS because:

✔ Your theme’s CSS loads later

✔ The cascade always favors later rules

✔ Remote CSS is not special

✔ RSP intentionally allows CSS overrides

✔ Only JS is locked down

This is why you’ve always been able to restyle the order form even though the actual CSS file doesn’t live on your server.

If you want, I can show you:

how to safely override any order‑form CSS
how to isolate your overrides so they don’t affect other pages
how to avoid fighting specificity
how to override even the hardest rules (like inline styles or !important)

Just tell me where you want to go next.

Understanding How the ResellersPanel Order Form Works

⭐ The short answer

⭐ The key mechanism: the `.htaccess` rewrite rule

✔ Any request to

✔ Instead, Apache rewrites it to

✔ That PHP file fetches the real file from ResellersPanel’s servers

⭐ Why the paths in functions.php look like this:

⭐ Where the real files actually live

⭐ Why RSP does this

⭐ Why you can override CSS but not JS

⭐ Why you couldn’t find the files in your theme or plugin

⭐ How the whole system works (succinct)

⭐ If you want, I can explain:

⭐ Why you can override remote CSS with your theme’s CSS

1. Load order

2. Selector specificity

3. `!important` flags

⭐ What actually happens in the browser

1. RSP’s remote CSS loads first

2. Your theme’s CSS loads later

3. Later styles override earlier styles

⭐ Why this works even though the CSS is remote

⭐ Why you can override everything except JS

⭐ Why the “Store Master Theme” order form loads instantly

⭐ Bottom line

✔ Your theme’s CSS loads later

✔ The cascade always favors later rules

✔ Remote CSS is not special

✔ RSP intentionally allows CSS overrides

✔ Only JS is locked down

Leave a Comment Cancel Reply

⭐ The short answer

⭐ The key mechanism: the .htaccess rewrite rule

✔ Any request to

✔ Instead, Apache rewrites it to

✔ That PHP file fetches the real file from ResellersPanel’s servers

⭐ Why the paths in functions.php look like this:

⭐ Where the real files actually live

⭐ Why RSP does this

⭐ Why you can override CSS but not JS

⭐ Why you couldn’t find the files in your theme or plugin

⭐ How the whole system works (succinct)

⭐ If you want, I can explain:

⭐ Why you can override remote CSS with your theme’s CSS

1. Load order

2. Selector specificity

3. !important flags

⭐ What actually happens in the browser

1. RSP’s remote CSS loads first

2. Your theme’s CSS loads later

3. Later styles override earlier styles

⭐ Why this works even though the CSS is remote

⭐ Why you can override everything except JS

⭐ Why the “Store Master Theme” order form loads instantly

⭐ Bottom line

✔ Your theme’s CSS loads later

✔ The cascade always favors later rules

✔ Remote CSS is not special

✔ RSP intentionally allows CSS overrides

✔ Only JS is locked down

Leave a Comment Cancel Reply

⭐ The key mechanism: the `.htaccess` rewrite rule

3. `!important` flags