|
Monday 04 October 2004 12:53:12 pm
Hello! I'm relating this here in case someone else has the same problem. :) Okay, so I never managed to understand how to do what the abovementioned article says, namely how it's possible to use nice URLs with views other than the default 'full' one. If anybody knows and wants to share, I'm still curious. :) Therefore, I realized that the only way to go was to manually add the custom view (in my case it's called showcomments) for each article to the URL translator. Practically speaking, each time an article is created I'd have to open the URL translator page and insert this info in the 'Create new URLs -> Translation' section: System URL: content/view/showcomments/<i>114</i> (where 114 is the node_id of the example article) Virtual URL: <i>nice_url_of_example_article</i>/comments However, this is okay if the number of articles is small, but as the number increases, it becomes time-consuming and ultimately impractical and unmanageable.
So I decided to somewhat automate this task.
To do this, I created overrides of the following templates, for the article class only:
<b>edit.tpl</b> and <b>edit_right_menu.tpl</b> (they are located in the design/standard/templates/content directory).
I called my overrides 'article_edit.tpl' and 'article_edit_right_menu.tpl': they are copies of the original templates, I just made some changes to them.
I did the overrides in the <b>admin</b> section; for reasons unknown to me, it didn't work at all when I did it in my specific site's admin section.
It must be noted that, in order for this to work, the article must have been previously published; otherwise, it doesn't have a node_id, but only an object_id, and trying to add it to the URL Translator doesn't obviously give the wanted results.
Therefore, the automation button must be shown only if the article has already been published (and thus has a node_id). Here are the changes I made in the templates. The original <b>edit.tpl</b> goes, at the very bottom:
</td>
</tr>
</table>
</form>
In my override 'article_edit.tpl' I applied this change:
</td>
</tr>
</table>
{section show=1|sub( $object.status )}
</form>
{/section}
The only thing this does is leave the original edit.tpl completely unaltered if the article has never been published, and hide the closing form element if it has. The reasons for the latter is that we will place the closing form element elsewhere if the article has been published, because it means we can display our automation button. More on this later. The original <b>edit_right_menu.tpl</b> goes, at the very bottom:
<input class="menubutton" type="submit" name="NewButton" value="{'New'|i18n('design/standard/content/edit')}" />
</td>
</tr>
</table>
In my override 'article_edit_right_menu.tpl' I applied this change:
<input class="menubutton" type="submit" name="NewButton" value="{'New'|i18n('design/standard/content/edit')}" />
</td>
</tr>
{section show=$object.status}
<tr>
<th class="menuheaddark" colspan="2">
<p class="menuhead">URL translator</p>
</th>
</tr>
<tr>
<td class="menu" colspan="2">
<p class="menufieldlabel">Comments View</p>
</td>
</tr>
<tr>
<td colspan="2" align="right">
</form>
<form action={concat("content/urltranslator/")|ezurl} method="post" >
<input type="hidden" name="NewURLAliasDestination" value="{concat('/content/view/showcomments/',$object.main_node_id)}" />
<input type="hidden" name="NewURLAliasSource" value="{concat($object.main_node.url_alias,'/comments')}" />
<input class="menubutton" type="submit" name="NewURLAliasButton" value="{'Add'|i18n('design/standard/content')}" />
</form>
</td>
{/section}
</table>
The added lines leave the original template unaltered if the article has never been published; otherwise, they show a new area in the right menu of the article edit page.
This area is called 'URL translator' and shows what custom views can be automatically added to the URL translator and provide a button to do said automation. What the code does in detail is this:
1) it closes the previous form element, which actually started back in edit.tpl, or article_edit.tpl if you prefer.
This is done because that form element has a different action attached to it than what we need. Indeed, the original form element goes:
<form enctype="multipart/form-data" method="post" action={concat("/content/edit/",$object.id,"/",$edit_version,"/",$edit_language|not|choose(concat($edit_language,"/"),''))|ezurl}>
and as you can see the action is related to the edit page itself. Messing with this would mean that the edit page would probably not work anymore, and we totally don't want that. However, we do want to do other stuff with the url translator automation button, so we need to close that form element right here (which is why we left it out in the article_edit.tpl before). 2) it inserts a new form element, this time with the wanted action. The action was taken straight from the url_translator template and handles the actual translation (including the insertion of our data in the database, that is). 3) it produces automatically the System URL and Virtual URL that I mentioned above, and inserts them into hidden input elements, so that, when the button is clicked, the correct data is sent to the database. By changing the value attribute of the two hidden input elements, you can customize the values that will be inserted in the database. Just remember to use $object.main_node_id to refer to the article node_id, it doesn't seem to me that it works in any other way (for more info on this, you can read my other post here: http://ez.no/community/forum/setup_design/how_to_get_node_id_of_object_you_are_editing#msg60191). As far as I know, if you change the name attribute of the three input elements, this doesn't work anymore, so I'd suggest avoiding that. And that's it. In the article right menu there's now a 'Add' button that automatically adds the data to the URL Translator.
<b>Notes</b>
This method isn't perfect. Indeed it has the following flaws:
1) to actually add the data to the URL translator, you have to first publish the article, then edit it again to have access to the button. This is necessary for the reasons I mentioned above, but it's somewhat non-optimal, as the article's writer has to go back and edit the article to be able to click the button.
However, it's still very much faster than getting manually the article node_id, going to the URL translator and typing all the data every single time, so overall I'd say it's not that bad.
2) when the 'Add' button is clicked, there's a redirection to the URL Translator page, where you can see that the data has indeed been inserted correctly.
However, apart from the fact that the redirection to another page might not be welcome in itself, there's a much more serious problem inherent in the redirection.
Indeed, if you make some modifications to the article, don't save them, and then click the 'Add' button, your modified data gets lost. There's an obvious workaround to this, that is to say hitting the browser's Back button, but if one is distracted and just opens the edit page again, the data is lost without recovery possibilites. :(
If anybody has suggestions on how to avoid this issue, it'd be very appreciated.
3) the 'Add' button always appears if the article's already been published. It is thus possible to insert the data several times in the database by clicking the 'Add' button more than once.
I'm working on a way to avoid this; I'll post an update to the code if I find it. That's all! Hopefully this is useful to somebody else. :) If you find bugs or better ways of doing this, I'd really appreciate it if you left a note. Antonio
|