Navigation tabs on top disappear

[Christopher Kramer]

Originally reported on Google Code with ID 241

The tabs ("Browse", "Structure", "SQL", ...) disappear in these cases:
- action=table_empty
- action=table_drop
- action=row_editordelete
- action=row_edit
- action=column_edit
- action=row_create&confirm=1
- action=column_confirm
- action=table_rename&confirm=1
- action=table_create
- action=table_create&confirm=1
- action=trigger_create
- action=index_create
- ...?

But it does not disappear in other similar cases:
- view=delete
- view=rename&database_rename=1

I think this is a bit unintuitive.
Why do the tabs disappear when I am about to drop a table (action=table_drop) but not
when I delete a database (view=delete)?
It is more or less the same on a different level.

I think that it would be best if the navigation tabs should always be there. This way,
you can navigate faster.
If you accidentally click to "Drop" a table but wanted to "Empty" it, it is faster
to click "Empty" directly instead of "Cancel" and then "Empty". 

Reported by crazy4chrissi on 2014-01-02 19:56:55

[dreadnaut]

I think that tabs should always be visible as long as the context is either a database
or a table/view, AND we are not in a multi-step process that should not be interrupted
by jumping to a different page (I don't remember if any multi-step processes exist
in PLA, probably not).

Tecnically, tabs don't actually disappear. They *only appear* for a limited number
of 'actions'. From index.php, line 1252:

if (!isset($_GET['confirm']) && isset($_GET['table']) && isset($_GET['action']) &&
(
   $_GET['action']=="table_export"
|| $_GET['action']=="table_import"
|| $_GET['action']=="table_sql"
|| $_GET['action']=="row_view"
|| $_GET['action']=="row_create"
|| $_GET['action']=="column_view"
|| $_GET['action']=="table_rename"
|| $_GET['action']=="table_search"
|| $_GET['action']=="table_triggers"
))

We can either add more elements to the check above, or refactor a bit —maybe an array
+ in_array would be more readable.

In the future, it would be nice to have something that tells us whether we are in a
db/table/view context.

Reported by dreadnaut on 2014-01-03 14:46:31

[Christopher Kramer]

I also think there is no multistep process in PLA. And we are always either in a DB
or table/view context. I think tabs should always be there, either the db-tabs or the
table / view tabs.
So I am not sure why we need to have a complex if there at all.
Maybe something like
if(isset($_GET['table']))
Would be enough in my opinion.

Reported by crazy4chrissi on 2014-01-04 17:58:00

[Christopher Kramer]

I just tried this and it looks good. But:
- the blue border between tabs and context currently disappears 
- we need to highlight the tabs differently
If action=column_edit (for example), the structure tab needs to be highlighted. If
action=row_editordelete, the browse tab needs to be highlighted

Reported by crazy4chrissi on 2014-01-04 18:02:49

[dreadnaut]

Related to this, we could also refactor the tab drawing code, see patch below.

Reported by dreadnaut on 2014-01-04 23:22:34

<hr> * Attachment: better-tabs.diff

[phpLiteAdmin]

• Tabs should now always stay visible. This fixes issue #241.
• Lots of forms used an uneccessary parameter $_POST['tablename']. It has been removed now and $_GET['table'] is used instead which needs to exists anyway (for the tabs, breadcrumbs etc).

→ <<cset 8f66ebf2a8de>>