Issue in developing a menu

creating some settings module…in the class Personal implements ISettings …{}

If in the __construct(…) IUser is mentioned the module doesn’t show up on the settings menu (without use OCP\IUser;)…
If the use OCP\IUser is mentioned there is an error about a double include of OC_User.
Cannot declare class OC_User, because the name is already in use at …/nextcloud/nc18/lib/private/legacy/user.php#60

Mentioning use OC_User; also doesn’t work.
Exception: Argument 2 passed to …Config::__construct() must implement interface OCP\IUser, instance of OC_User given, called in
So they are not equivalent…

The Dev manual is rather silent on the issue. (or the use of IUser & Methods as such anyway).
Can enyone enlighten me?

I need to get the Displayname of a user. btw, IUserSession seems to be a documentation deadend as well.

Probably if you post a code snippet (or better the whole class).

See here:

An attempt to try to pickup a nextcloud app that was dropped due to too many to rapid API changes. (several of the apps i had suffered from that fate).
Trying to start to program for Nextcloud does indicate there is a lot of issues in the API.
Comparing several apps to see how “things” ought to be done only produces more confusion not answers. I have trouble to find the right stuff in the provided documentation. Even the example is a kind of hotchpotch.
I do have the impression the learning curve is almost looking like a wall. (pure vertical line).
Available documentation is in conflict… ( / tags for )

$this->user as object of type IUser has no method getUser also the a IUser object is not expected for getUserValue. Solution: $this->user->getUID().

$this->User->getUser() same as above and the attribute name is wrong. Solution: $this->user->getUID().

It seems that you dont need a full user object in config. Probably good to just pass the UID to Config.

Is there some description of the classes, attributes & methods?
That this “documentation” is lacking some details might be an understatement:

A link in that chapter point to the github location would have helped…
Well i was hoping for a bit more:
take a look at these:
man 2 open or on the web
Which is a far better description compared to the the pointer to:

Another OS

esp. the last one are Excellent manual pages. (An OS that has hardly undocumented “features”…)
That is where i come from.
The other examples in the nextcloud documents doesn’t expose a very consistent view, the “official” apps hardly compare to the documentation and they all use their own unique method / access.
At least i can much better understand why people abandoned their apps. I understand there is no “best” way… although this proliferation ways to solve things will create future maintenance problems.
Continuously breaking things only goes to the moment nobody cares enough anymore to fix it.

Have you considered to use a proper IDE to develop your app? Most modern IDEs are able to index the code and help you finding the right methods and point you to possible errors.

As example. PHPStorm already tells me that something with getUser is wrong. Because there is no such method on that object. Also the User typo is highlighted.

As this is one of the few thing i do in PHP i have no dedicated tool chain for that.
As such vim is my main tool…
I recently installed vscodium (after vscode appeared to be rather network talkative).
And i do not see a lot of improvement (except for slightly better syntax coloring and indenting markup + support for showing php internal functions etc.)

It surely doesn’t verify typed statements.
I doubt it will be worth wile to shell out a sum of money for some hobby project.

Please make sure to configure VSCode accordingly and install to have some auto completion.

wrt. Documentation for V14 it was still there:

Yes. That seems to be broken for newer versions. Here is the related issue:

I know this is an old thread, but I think some of the points @nextnoci is making are still valid. Using an “IDE” with bells and whistles certainly helps, but it doesn’t take away the fact that the Nextcloud API documentation is in serious need of an overhaul.

There are, now, better samples/skeletons, etc. But there are still a lot of questions that seemingly can only be answered by reading source code, line by line.

At the advent of the IBM PC, that may have been OK; getting their Technical Reference Manual gave us the assembler source code of the BIOS and we could figure out how to interact with it. But this is some 40 years later, and I really think that if Nextcloud wants to attract more competent developers and up the game as far as quality apps and supporting infrastructure goes, doing everything possible to document the Nextcloud API is key.

This is, IMHO, far more important than tossing around Hub 3, Hub 4, etc as the greatest thing since sliced bread.

I think the way many Nextcloud applications interact with the user is testimony to the fact that the apps don’t often interact well with each other.

Don’t get me wrong, I really love the Open Source community, and Nextcloud is one part of that; and the thousands of hours that amateur and professional developers put into making it and other OSS better deserves recognition. But to say that the Nextcloud API is well documented and easy to use is not “quite” true from my point of view.

Just my two cents.


thank you for your constructive feedback, I really appreciate it. I am happy to tell you that my team is investing at the moment in the API documentation and there will be updates about this in the future.

1 Like

That’s great to hear. Feel free to let me know if there’s something you need help with and/or if I can be of assistance as a proof reader.

1 Like

Thank you! :heart:

1 Like