I’ve fixed the cookie issue.
I’ll post tomorrow the working version.
Need some rest now.
:-)
Good stuff once again heliotrope!
"He can have a lollipop any time he wants to. That's what it means to be a programmer."
-
☆ A M B ☆
- 1,056 Posts
Seemed to slip under my radar, but this is indeed a great addition to the manager. Though I don’t use the View Doc page much myself ( DocTree-hugger here

), this is a nice representation of the document hierarchy... so, what if a Child also has Children? I would imagine it would be displayed as a Container, and then clicking "View" would simply reload in View Doc, the tabs/child list, etc?
Are child containers denoted somehow?
Before going to bed I’ll try to answer your question:
The view children tab appears only when the doc is a container.
On reload the page displays the flat view if you were in the view tab in the previous page.
I could add the doc type (container) in the displayed data in the listing and how many childs they have.
I’ve done this mod because the tree view has limit when you have thousand docs.
And IMHO, that’s nice to have the choice between tree view and flat view to browse the content.
:-)
Looks great.
Quote from: rthrash at Jan 12, 2007, 10:07 PM
That’s quite handy indeed! I’m interested. Care to add the missing introtext and other meta data fields as well to the general tab? 
ie
http://modxcms.com/bugs/task/566 ... As it happens I’ve just had a go at doing this on 2226 and it’s very straightforward. I’ve worked out the code for ID, summary (introtext), menutitle, publishedon and publishedby, and the page is much more useful reference now. And I really do think that adding publishedon will help dispel the misunderstandings around pub_date. Also, no new lang fields are needed.
I can add this again quickly once the other changes are finalised, or tell someone what to add.
@ryan & paul:
Should I post the changes I made or it’s no more useful ?
:-)
Hi ,
I need an advice.
As i could not manage the cookie stuff from within document_static to deal with the tabPane (setcookie returns an error: output already started in header.inc.php) to create only one tab when isfolder=0, I have to display the "view children" even if the doc is not a folder.
So I’d like to know what you prefer:
Option 1: display a message : "this doc is not a folder" without the create doc here button.
JFYI, In case we display the button, if the user creates a doc with a parent which is not a folder MODx changes the parent type to container.
Option 2: display a new error message "This this doc is not a folder, adding a doc here will change its type." with the "create doc here" button.
thx
:-)
In fact that’s not so simple cause if the user has no right to create we’ll have to change the message.
Sounds like a headache ;-)
Nevermind, I’ve done the best I could to solve this.
I’ve left the create bar if user has right to add content cause it seems to me that’s a feature.
I’ve changed the "no_children_message" to This document has no childrens yet.
Here is the final change log:
changelog: document_data.static.php
- Added in /manager/includes/extenders/maketable.class.php
- Changed in maketable.class line to skip class="clearfix" and added global $_lang support
removed the <select> "per page" due to cookie
- Number of results to display per page is based on MODx settings site
- Added these lines in english.inc.php (start line 207)
$_lang["view_childs_documents_in_container"] = "View childrens";
$_lang["documents_in_container"] = "documents in this container";
$_lang["no_documents_in_container"] = "This document has not yet childrens.";
$_lang["pagination_table_first"] = "First";
$_lang["pagination_table_last"] = "Last";
$_lang["pagination_table_gotopage"] = "Go to page";
- Added css class in style.css for table pagination
- Modified viewdata to display introtext / metatags, added tab view child list.
- The create bar (document & weblink) will not be displayed if user has no right to create
- The edit bar will not be displayed if user has no right to edit.
:-)