Jump to content

Developer documentation suggestions


twhiting9275

Recommended Posts

This is a complete and total embarassment for WHMCS. For a year (or better) now, you've had documentation so misconstrued, so spread out everywhere, so unavailable that it's just flat out not funny. We're constantly told "tell us if you find something", but, you constantly refuse to do the jobs tht you should have been doing in the first place... Bring back working development documentation . It was WORKING , and you broke it. How hard is that to understand?

People bookmark things for a reason. They USE things for a reason. You need to have just a bit of respect for developers (who, by the way are also your customers and license holders). Instead of making search so damned complicated, bring it back to the way it used to be. 

When I type in a search query, I expect anything with that query to show up in a page, not a drop down. Instead, I have to go fighting , just to find anything in reference to the curlCall functionality, or hell anything that SHOULD be easy to find with a simple search query.

I'm aware that things evolve over time, but you need to be aware that people search for things, and expect them to be there . Instead, you redirect, throw things everywhere and just mess everything back up, as usual.

 

For the love of GOD, please get a WORKING development documentation site up. It shouldn't take this long to do this!

Link to comment
Share on other sites

  • WHMCS Support Manager

Hi Tom,

Thanks for your feedback on our developer documentation and the search feature in particular.

We have read and acted upon the feedback we have received in the past regarding the developer documentation, particularly when users were finding areas which were outdated or no-longer applicable. As such we have invested time and money in tools which automatically build the documentation based upon the releases we make; this means that we can be confident that the documentation is relevant to the actively developed version. It's also based in GitHub as we know that is a tool a lot of developers prefer.

This applies to our developer documentation portal: https://developers.whmcs.com/ and well as our internal class documentation: https://docs.whmcs.com/classes/

 

We have indeed also made some changes to the search tools to provide a more modern UX and instant search results. I understand that you may not like the current implementation, so in addition we are exploring ways to implement a full-page search for traditionalists who prefer that UX too.

If there is some particular information you feel is missing or a page you were unable to locate, please do let me know the details so that we can look to improve in future.

 

Link to comment
Share on other sites

John,

To be honest, this still doesn't work as it should. You took a fully functioning documentation site, tore it apart, and then just forgot to put large amounts of things back in. Forgot, or were just too lazy to put them back in. At this point, I'd go with just too lazy, since it's been a year + now.

Again, this isn't really hard to grasp here. You need to update this to include everything that was in the old documentation.

A perfect example of this is right here . You've spread all of this information out and hidden parts of it so that it's not actually in the system any longer

As i said, you really need to have respect for your clients, and people who spend more than enough time trying to extend your product. There's a reason bookmarks exist, and to continually change things up for no valid reason is just ridiculous. Adding to this, no, the search function doesn't work properly. If it did, when I hit enter, or return (like with any other search engine), the product would be right there. Ajax is not an appropriate response for this, not at all.

Link to comment
Share on other sites

7 hours ago, twhiting9275 said:

To be honest, this still doesn't work as it should. You took a fully functioning documentation site, tore it apart, and then just forgot to put large amounts of things back in. Forgot, or were just too lazy to put them back in. At this point, I'd go with just too lazy, since it's been a year + now.

to add my tuppence to this, I don't see why the documentation should only cover the active version. :?:

if in one years time, a user (who let's say is using v7.3 and doesn't want to upgrade) goes to a developer and wants a solution to an issue for that version, the developer should just be able to go to the v7.3 dev docs site and find all the relevant information for that release... they shouldn't have to view v8 docs and then try to figure out what/when changes were introduced and try to work back.

WHMCS already do something similar with the Class docs, but maintaining docs for each (perhaps just major) release requires virtually zero work... so when v7.5 is released, you copy the existing docs to a v7.4 folder/link, and then duplicate and modify for v7.5 and so on... once 7.5 is released, you can totally leave the v7.4 docs alone.

yes, they'll be duplication... but it will be relevant duplication... and duplication is better than omission (which is what we have now)... we should never be required to use archive.org to find information.

+1 for Tom raising this on a seemingly yearly basis...

 

Link to comment
Share on other sites

  • WHMCS Support Manager

Hi @twhiting9275,

The information you're referencing on that archived page is now located in the "Advanced " section: https://developers.whmcs.com/advanced/

Regarding the cURL information which is not reproduced in the new developer documentation, this is because we now recommend using the Guzzle library instead. Guzzle has been available in WHMCS for a long time and offers more flexibility and control over remote requests. We also now recommend using the SendEmail local API function in place of the sendMessage function.

I searched for a couple of the code samples and phrasing and I received the correct pages in the search results. Is there a particular search term which isn't returning an appropriate result for you? Specific examples would be most helpful in understanding the issue you are encountering.

 

 

 

Link to comment
Share on other sites

John,

Whether you 'recommend' something or not is rather irrelevant. The feature exists, and you chose not to move the documentation for said feature from A to B.

Nobody's going to learn 'guzzle' simply to use a simple curl call. That's not how life works. You've taken something rather simple and turned it into a complex issue. You've taken working documentation, and turned it into a mess.

You can claim you support (and recommend) Guzzle all you want, but where on your documentation does it show this? Oh yeah, nowhere.  So, basically, the person is on their own.

That was just one of the many examples here though, and one of the things that are wrong about the way you chose to handle things

Your clients (and developers) need stable development documentation. People rely on bookmarks , left and right, but you've yet to fix either of these issues. Instead, hey, just figure it out on your own is what you say.

We, the paying customers, shouldn't have to tell you 'something isn't working'. That's your job to replace, when it comes to documentation. If it was there before, then you need to bring it back. If it's old, great, then let people KNOW the functionality has been removed, in the documentation, not simply by removing it! Again, some actually do work with older software and develop for it.

Link to comment
Share on other sites

On 1/29/2018 at 6:18 AM, brian! said:

to add my tuppence to this, I don't see why the documentation should only cover the active version. :?:

if in one years time, a user (who let's say is using v7.3 and doesn't want to upgrade) goes to a developer and wants a solution to an issue for that version, the developer should just be able to go to the v7.3 dev docs site and find all the relevant information for that release... they shouldn't have to view v8 docs and then try to figure out what/when changes were introduced and try to work back.

WHMCS already do something similar with the Class docs, but maintaining docs for each (perhaps just major) release requires virtually zero work... so when v7.5 is released, you copy the existing docs to a v7.4 folder/link, and then duplicate and modify for v7.5 and so on... once 7.5 is released, you can totally leave the v7.4 docs alone.

Quick comment on version specific documentation, that is actually far easier to do when the majority of the documentation is automatically generated from the code instead of being a wiki site with its own publishing process and no concept of branching, etc. So the move John discussed is actually what opens up the possibilities for version specific developer documentation. 

Link to comment
Share on other sites

11 minutes ago, WHMCS Nate said:

So the move John discussed is actually what opens up the possibilities for version specific developer documentation. 

but as Tom suggests, it needs to move in both directions... so going forward with new releases, but more importantly, accurate information about older releases too.

Link to comment
Share on other sites

13 minutes ago, brian! said:

but as Tom suggests, it needs to move in both directions... so going forward with new releases, but more importantly, accurate information about older releases too.

I can see how both are valuable and helpful. I don't make the end choices about which of the many valuable things I work on next, but I'm thinking about if it would be possible to do version specific developer documentation and will have some follow up conversations about it. 

Link to comment
Share on other sites

Yet another one of those irksome things that go right along with this. Trying to get help on this via ticket just led to swearing up and down, because the 'tech' didn't get that you should have documents for this already.

You've got a ton of documentation (via sample modules) on github, related to almost every module type, EXCEPT for fraud . Hell, you've even added notifications, yet, still nothing for fraud modules (which are their own  type).. So, how are we supposed to integrate things like fraud modules properly if we don't have a functioning example of this?

Link to comment
Share on other sites

11 hours ago, twhiting9275 said:

So, basically, it's accept ours or do nothing. Talk about poor decision planning there.

Not quite, there are hook points when an Fraud Check is requested that allow you to write your own code and then surpress passing to a fraud module. You can then use the API to mark the Order as Fraud based on the results of your own code operation. Like many things in WHMCS there are more than one way to skin the cat, relevant documentation links:

https://developers.whmcs.com/hooks-reference/shopping-cart/#runfraudcheck

https://developers.whmcs.com/api-reference/fraudorder/

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use & Guidelines and understand your posts will initially be pre-moderated