Well it definitely is possible. I have something that almost works - the markup all looks good, but there is a lot of strangeness going on with the way this page uses DataTables that I still need to iron out. Basically what I’ve done is add a couple hooks that will let you modify the edit table’s columns as such:
function filter_table_headings($headings)
{
// first make sure we're on the right page in the CP:
if(REQ == 'CP' && $this->EE->input->get('C') == 'content_edit')
{
// alter content > edit headings with a new heading
$headings[] = array('data' => '# of relations', 'width' => '100px');
}
return $headings;
}
function filter_table_data($data)
{
if(REQ == 'CP' && $this->EE->input->get('C') == 'content_edit')
{
// get some data from somewhere
$additional_data = array();
// alter content > edit data with a new column
for($i = 0; $i < count($data); $i++)
{
// the first column is the entry_id
$entry_id = $data[$i][0]['data'];
$data[$i][] = array('data' => $additional_data[$entry_id]);
}
}
}It’ll probably be a few days before I can iron it all out so it actually works correctly. This is great because my goal with Wallace is to add in as many useful hooks as possible. Looks like these will be the next ones available. 😊
Totally agree, since EE can be moulded to so many requirements it’s almost a given that clients will want to see custom field data, category data and more in a column on the edit page. I think it would be super useful if we could have a hook for each of the key list type pages in the control panel (entries, members, comments etc)
Totally agree, since EE can be moulded to so many requirements it’s almost a given that clients will want to see custom field data, category data and more in a column on the edit page. I think it would be super useful if we could have a hook for each of the key list type pages in the control panel (entries, members, comments etc)
If I can figure out why DataTables is preventing this from working then you should be able to change any table based view in the CP.
I’m going to join the foray here with my request for publish/edit hooks. submit_new_entry_start and submit_new_entry_end were pretty awesome for custom functionality, and I am really hesitant about hijacking $_POST using the sessions_start hook, but if I have to, I will.
There are some wicked things that I would like to be able to do if there were a couple of hooks in the actual template parsing method too.
Why were so many hooks removed, and why the apparent reluctance to add them back, or add completely new ones? Hooks are a beautiful thing and let us implement some pretty amazing features that the EllisLab team may not have thought of.
I’ve been following this discussion thread for awhile, hoping Ellis Lab would respond positively to the desire for more hooks in EE2. I was just looking at the Forecast page, and I noticed this item:
show_full_control_panel_end Developers need a way to add CSS and JavaScript to the control panel, without the baggage that came with the legacy show_full_control_panel_end extension hook, and without making an Accessory just for that purpose. Make it so.
It shows a status of “released.” It’s not clear what that means. How did they make it so? Anyone else following this thread aware of this development?
http://expressionengine.com/blog/forecast/
Elis Lab added cp_js_end which provides a solution to only part of what show_full_control_panel_end allowed. I have not really looked at it closely but it’s name certainly implies that it only allows adding Javascript code. The description cited I think misses the point of show_full_control_panel_end almost completely - it is used for so much more than just injecting CSS and JavaScript.
But remember, my Wallace extension gives you the full freedom of the show_full_control_panel_end hook back, and it is free and will always be free. You just write an extension that responds to that hook and it’s behavior should be very nearly identical (testing recommended of course). As I can I will re-implement other missing hooks or at least equivalent (or better) functionality through this extension. I’m doing this because there are several hooks I have come to rely on in my custom CMS builds for clients that I just can’t live without - and this is certainly one of them.
Elis Lab added cp_js_end which provides a solution to only part of what show_full_control_panel_end allowed. I have not really looked at it closely but it’s name certainly implies that it only allows adding Javascript code. The description cited I think misses the point of show_full_control_panel_end almost completely - it is used for so much more than just injecting CSS and JavaScript.
Absolutely.
Developers often use show_full_control_panel_end for making CP changes server-side, e.g. for adding or removing some HTML elements. If you will try to do the same client-side you will end with some elements suddenly popping-up and other elements flashing up and suddenly disappearing after page is loaded. It would be ugly.
To be clear, the “official” alternative(s) for show_full_control_panel_end are cp_js_end and cp_css_end? I’m having trouble finding info on cp_css_end in the EE2 docs for developers, but apparently a few add-ons use it: http://devot-ee.com/hooks/ee/cp_css_end
Packet Tide owns and develops ExpressionEngine. © Packet Tide, All Rights Reserved.