wordpress-sdk
wordpress-sdk copied to clipboard
Forum Support menu item showing; not obeying config setting.
Actual Behavior:
What is the issue? (*)My plugin (my-plugin-name) has a support slug (my-plugin-name-support). When I navigate to that page, the menu item for 'Support Forum' created by Freemius is shown even though the helper function specifies support=false. If I visit any other page in the plugin (ie, without "support" in the slug,) the Support Forum item is hidden as it should be.What is the expected behavior?The Support Forum menu item never appears if it is configured to not be shown. Versions: (*)Freemius SDK Version:2.1.3WordPress Version:4.9.8PHP Version:7.2.3
Plugin / Theme: (*)
Name:my-plugin-nameSlug:my-plugin-nameFreemius ID:2770
Additional Information:
Browser Type: (*)FFBrowser Version: (*)63OS: (*)Win10Stack Traces:
Note: (*) indicates required information. Without this information, your issue may be auto-closed.
You can find your Freemius SDK version at
/freemius/start.php
You can find your Freemius product ID in the Freemius dashboard:
SETTINGS -> INTEGRATION.
Do not modify the titles or questions. Simply add your responses to the ends of the questions. Add more lines if needed.
Here's the relevant bit of code from the helper function:
$mpn_fs = fs_dynamic_init( array(
'id' => '2770',
'slug' => 'my-plugin-name',
'type' => 'plugin',
'public_key' => 'pk_59e120eadd4eee78d5acda243f4c8',
'is_premium' => false,
'has_addons' => false,
'has_paid_plans' => false,
'menu' => array(
'slug' => 'my-plugin-name',
'account' => true,
'contact' => false,
'support' => false,
'parent' => array(
'slug' => 'my-plugin-name',
),
'secret_key' => 'sk_somevalue',
),
) );
A little more background on this...
I'm building a highly extensible WP boilerplate plugin which uses a slug (et al) my-plugin name for the primary menu. Extensions can then be installed which may (or may not) add menu items, thus extending the base plugin with arbitrary functionality. This results in menu slugs such as my-plugin-name-settings, my-plugin-name-onboarding, my-plugin-name-support... This last slug resulted in Freemius' built-in Support Forum menu item to be shown in spite of the code above. I should note that my own menu item worked correctly, ie, displaying my support extension's page when clicked.
As a workaround, I have renamed my plugin's extension to "Help" so Freemius' Support Forum item won't inject itself into the menu... but, the word "Help" sounds amateurish... the extension should be able to be called Support as it has all along.
In full disclosure, I haven't dug through the SDK codebase to see how much work it would be to solve this issue. To be honest, I haven't seen a class this huge in a very longggg time! :)
...an easier "fix" might be to simply document that there are some reserved slugs (ie, account, support, whatever) that should be avoided.
@johnalarcon it is working that way by design. If a user opens a hidden page, we do want to show them the context of the page by showing the hidden submenu item. Could you please explain why do you find it as an issue?
If the support menu item is flagged to not be displayed, ie, using the code I added above (support => false,) then the menu item shouldn't show, and that slug should be available to another part of my plugin, which is already using that slug. If I disable the Freemius support page (like above,) I should be able to use the support slug (ie, my-plugin-name-support) without invoking Freemius functionality that I've disabled. The thing is: I don't need a submittable support form - that is handled outside of Freemius. If you contend that this is "by design" then the documentation should be updated to indicate all the slugs that are reserved by Freemius.