Migrating cPanel api1 cpanelprint(CPDATA)

cPanel & WHM Version
88.x

CloudNexus

Member
May 18, 2018
20
2
3
Netherlands
cPanel Access Level
Root Administrator
Hi there,

I'm nearly done migrating away from cPanel v1, but there's a single thing that's still left.

I use the cpanelprint 'function' in LivePHP in the following way:

$this->account = $this->cpanel->cpanelprint('$user');
$this->homeDir = $this->cpanel->cpanelprint('$abshomedir');
$enabledFeature= $this->cpanel->cpanelprint('$CPDATA{\'my_custom_feature\'}');


The first two can easily be replaced with UAPI, but the last one is no so simple. Apparently cpanelprint calls a v1 api in the background, causing deprecation notices.

How am I able (from a cPanel LivePHP) context to read a setting from the users hosting-file (/var/cpanel/users/username)? Is there an alternative call I can use? I checked both uapi (doesn't seem to be able to this using the 'Variables > Get_user_* command) and cpanel v2.

Any tips would be helpful.
 

cPanelTJ

Product Owner
Staff member
Jan 29, 2019
84
39
93
Houston, TX
cPanel Access Level
Root Administrator
Twitter
Hi @CloudNexus ,

Thanks for reaching out on this issue. I am the product owner in charge of the cPanel API 1 retirement project. Let me get with the team this morning to get you a recommended solution by end of today at the latest.
 

cPanelTJ

Product Owner
Staff member
Jan 29, 2019
84
39
93
Houston, TX
cPanel Access Level
Root Administrator
Twitter
Hi @CloudNexus ,

When you say "feature", is this a reference to a custom feature that is added and managed by the WHM side of our product? Or are you referring to a specific setting within your own plugin?

If this is a feature managed by WHM, then you could use UAPI Features::has_feature to determine if that feature is enabled for the cPanel account and here are some instructions of how to set up that feature registration for the plugin.

If the case is the latter, where you are looking for a specific setting that you created/added to the user's settings, then we may need more information into what the setting is and how you are intending to use it in your code.

I took a look at (assuming) your plugin from here: NexusCore - .NET Core for cPanel & WHM

If that is the code in question, we determined that the UAPI Feature::has_feature would work for a number of features that are already being added by the plugin. For example (API over CLI):
Code:
uapi Features -user=test_user  has_feature name='nexuscore_sdks'
--- 
apiversion: 3
func: has_feature
module: Features
result: 
  data: 1
  errors: ~
  messages: ~
  metadata: {}

  status: 1
  warnings: ~
Any of these specific features can be detected for an account in the same manner:
Code:
nexuscore_appsettings=1
nexuscore_devtools=1
nexuscore_help=1
nexuscore_logs=1
nexuscore_sdks=1
nexuscore_sql_backups=1
nexuscore_sql_connectionstring=1
nexuscore_sqloverview=1
nexuscore_sqltools=1
nexuscore_sqlwizard=1
This then would perhaps not require the enable_dotnet_core=y in /var/cpanel/users/$user.
 
  • Like
Reactions: CloudNexus

CloudNexus

Member
May 18, 2018
20
2
3
Netherlands
cPanel Access Level
Root Administrator
Thank you for your detailed and in-depth answer! So quick
Note: I have 2 plugins (one for dotnet, and one for microsoft sql server for linux), both act in the same way.

So the situation is a bit different:

My 'add-on" is not just adding some extra live.php templates to the front-end, it's also changing the way the hosting package is working, using package extensions.

If the setting on the 'package extension' is enabled, it means that this hosting package will be proxied to an internal application (kestrel) serving the http request. Enabling this setting will set the "enable_dotnet_core" in the user hosting file (See attachment).

The reason I need to know whether this is true or false is simple:
A hosting package can have the "setting" disabled (meaning that the website will be served with apache+php like normal) but the 'features' enabled.
The result will be that the icons and pages (the list of features that you showed) will show up in the cPanel front-end for hosting customers, but once they go there it will throw errors, because enable_dotnet_core (package extension variable) is not enabled for this account.

There is no hard 'connection' between the features and the actual under-the-hood feature, and I'm trying to enforce it this way for reasons of user experience - I can't allow users to make changes to their "dotnet hosting configuration" or "create SQL Server databases" when that feature is not enabled for them. Usually this happens when server admins add the feature to a package that doesn't have the asp.net core plugin enabled, but I don't want to bother the end-user with this and give at least some sense of feedback to them that something went wrong.

Basically on the aforemended feature .live.php pages I do something like this:

if ($cpanel->checkIfDotnetIsEnabled !== true)
{
// show error and stop processing the page.
}


I hope I am clear, if not please let me know how I can clear this up.
 

Attachments

cPanelTJ

Product Owner
Staff member
Jan 29, 2019
84
39
93
Houston, TX
cPanel Access Level
Root Administrator
Twitter
Thank you for the extra details. We are going to explore expanding the output in Variables::get_user_information later this week to include custom key value pairs added by plugins. Sadly, this won't be an immediate solution as it might take 4-6 weeks (optimistically) to get it out to a production release for version 86.

The good news is that we will not be removing this LiveAPI functionality in version 88. If you're wanting to silence the warning in the email notification in the meantime, a quick and dirty option using PHP could be to parse the file and find the value. We're still exploring a few alternatives this evening. I may have something else for you tomorrow.
 

CloudNexus

Member
May 18, 2018
20
2
3
Netherlands
cPanel Access Level
Root Administrator
Thank you for the extra details. We are going to explore expanding the output in Variables::get_user_information later this week to include custom key value pairs added by plugins. Sadly, this won't be an immediate solution as it might take 4-6 weeks (optimistically) to get it out to a production release for version 86.

The good news is that we will not be removing this LiveAPI functionality in version 88. If you're wanting to silence the warning in the email notification in the meantime, a quick and dirty option using PHP could be to parse the file and find the value. We're still exploring a few alternatives this evening. I may have something else for you tomorrow.
Thank you for the update and I really appreciate the direct contact!

I tried alternative ways of getting the value for the user, but this would involve some fairly dirty poking around (cPanel .live.php context > call perl handler using uapi (user context) -> Call adminBin perl handler (that runs under administrative privileges) that can get the file contents.....but I'd rather not ;-). As long as I can explain this to my customers it's good enough for now. And the most important thing is that the end-user won't feel a thing, as this cpanelprint will not be removed yet (even although I will move over to uapi as soon as it supports getting that data.

Glad a found a hole for you to plug so you can make the migration to uapi even more feature complete (yay to uapi).