It looks like if plans have different prices, the default price is always 1 site, even if this price is hidden. Here's the pricing page:

When checking out, even if the 3 sites license is selected, it defaults to single site license on checkout:

I believe this is because:

1. selectedLicenseQuantity state is only updated on change, and not on load.
2. selectedLicenseQuantity is a single value and not scoped to plans specifically. I think each plan component should keep track of this value, rather than a global state value. Or if stored in global state, should be an array or object to keep track of which plan has which quantity selected.

This would allow for more flexibility.

Everything is quite OK at the desktops (all visible) and tablets (horizontal slider):

But nothing works on mobile phones: Only one block is visible and "PRO" titles are not clickable:

When in the checkout page, the bottom clips when you scrolll the page

It would be great to integrate the option for defining products. In my case i have only one product without different plans and based on more source code security i will be using add-ons. Therefore it would be great to define up to four products for the pricing page. In my case these would be bundles with the main plugin and different add-ons.

Add information on developing the pricing page (rather than just testing it).

e.g. Show how to use symlinks to dynamically add the dist folder to the freemius folder on your local WP site. I think it's important we get as many Freemius partners as possible testing/contributing to the pricing page, so it makes sense to make this as easy as possible.

In the div "fs-selected-pricing-amount" the values after the "." are missing, see screenshoot above

Right prices are 3.99 and 7.99, as you can see in this second screenshoot

At the moment there is no comprehensive readme on the master branch so nothing displays for visitors to the repo landing page. Until develop is merged into master we should probably update the readme in the mean-time.

The result size of production build's file (freemius-pricing.js) is 2.5Mb.

Why it is so big? This is a size of the average website, but there is only 1 page with several pricing blocks and slider.

I think you should find out why the file is so heavy and try to reduce its' size.

(I am a React-developer, so I know that a lot of React-code can weigh a little in the production build)

I know the project is in development, but I've been testing it out and I noticed the title and logo styling aren't consistent with the rest of the page:

I've already got a fix and will request permission to create a branch, then a pull request. Thanks!

Here's my current pricing. I only have 1 product plan but available in different number of sites. My plans are annual only.

When I try out the new pricing page, I'm getting this:

A few things:

1. Both tiers say "Professional", is there a way to change this?
2. For annual plans, is there a way to display an annual price instead of the monthly price? (per year instead of per month)
3. Maybe it's better to add some default colors to the heading and button
4. Is there a way to note a "Most popular" plan?

For 1 and 2, the pricing can end up like this:

🐞 bug report

Behavior:

• In the documentation, it says the filter freemius_pricing_js_path expects a relative path to the freemius-pricing.js.
• But in reality, it expects the absolute path.

So given, I have the js file in assets/freemius-pricing/freemius-pricing.js the following code will not work:

// BAD CODE, WILL NOT WORK
my_fs()->add_filter(
	'freemius_pricing_js_path',
	function( $default_path ) {
		return '/assets/freemius-pricing/freemius-pricing.js';
	}
);

But this will

// GOOD CODE
my_fs()->add_filter(
	'freemius_pricing_js_path',
	function( $default_path ) {
		return \plugin_dir_path( __FILE__ )
			. 'assets/freemius-pricing/freemius-pricing.js';
	}
);

Versions: (*)

• Freemius Pricing Page Version: develop
• Freemius SDK Version: develop (2.4.2.2)
• WordPress Version: 5.6
• PHP Version: 7.4

At the moment there's only a production build step which means every time the code is edited you have to manually npm run build.

To make the workflow more effiecient it would be better to also have a development script that watches files and builds a development version of the pricing page (i.e. code not minified etc. to keep compile time to a minimum).