CONTROLLERS, single method or different methods for different actions?

You would want to add separate methods like add, edit, delete etc;

Yes I realise this, but the question is whether my view has a single form routing to a single method, and that method then determines what the user wants to do. Or whether I have a separate form for each action.

sounds legit

so here is another way - yes (obviously) you should have separate methods, because you need to call different validation etc. but you also can call the same form url in your different forms - just put a hidden form field like

PHP Code:

form_hidden( 'task', 'editcolors' ); 


then in the controller method that the form goes to - pick up the 'task' and route to the correct method based on the hidden form field - and make the method private like _editcolors()

Well that is kind of what I meant by Jiggery Poker. Another option would be to give different buttons name and value, so the controller knows if the user hit "save" or whether they hit "delete colours"

But if I had separate forms all going to the same controller, using a hidden task field, had I might as well not just have separate forms routing to separate controller methods?

Nitpicky, but ... s/private/inaccessible/
Terminology is important.

CodeIgniter may prevent controller methods prefixed with an underscore from being publicly accessible, but that's just a legacy feature left from the PHP4 era when the underscore-prefixing convention was used to denote methods that shouldn't be called from outside of that class.
Technically, it's just an informational thing; CI developers at the time have decided to make it functional due to lack of better alternatives.

But we're in the PHP7 era now and "private" has a specific meaning. Also, making controller methods really private by using the keyword works just fine - you don't need to prefix those with an underscore and they still won't be routable.

Thanks for the clarification. I've been doing private methods as:

private function _my_private_method() { }

Let's say I have a Controller and a View where you can edit a customer (where 123 is the customer's unique ID):
/customer/edit/123

do not do this. i know its in almost every api tutorial to do it this way - but if you have any choice at all do not because exposing the customer id, or a db record id in the URL for a page that you need to be logged in to access - is insecure.

No it's not, at least not in most cases.

It's a minor information leak at best, and could be classified as such solely because of the logical argument that, if something requires login to be seen, it is therefore a secret to unauthenticated users.
Following this line of logic, anything that is accidentaly seen by outsiders is an information leak - even silly stuff like visitors count for the past hour.

In my case this is a system which requires users to login, and those said users will all be related (i.e. part of the same organisation) so no data should be leaked or accessible to the outside. For me personally, it makes no odds whether the customer ID is in the URL or in a hidden field, since a right-click and "view source" is hardly a deterrent to anyone who knows what they're doing.