Child pages
  • Allow developer to prevent deletion of specific pages in structure
Skip to end of metadata
Go to start of metadata

Imported From:

There are some cases, when we have page on front-end with hardcoded link, even, when link is <inp2:m_Link template="id:12"/> with automatic path building to template. When user deletes this page, then link will be broken until he create new page with same id (which is impossible) or with same name (he never imagines, that he should do it to fix it's problem).

Today is strange approach to create template, that just includes "default_design". This way page becomes system and therefore can't be deleted from structure. I'm against such approach since it's not really understandable, when you look on that template with one include why it was created in first place.


I propose we create new field for categories/sections, that will indicate, that given page can't be deleted without specific advanced permission, which administrators don't have and maybe only super-root will have (or while in debug mode). Also we need to update such column for all system pages and in future use it nor page status (system or not) to determine if it can be deleted.

Related Tasks

INP-539 - Getting issue details... STATUS


  1. I can't really remember why we needed protection against system page
    deletion at all. When system page is deleted, then associated physical
    template is not deleted. Then user can use "Refresh" button in "Themes"
    section and our section, that we just deleted by accident will be back in no

    At the end I see this like this:

       1. add new field "Protected" (Yes/No) on category editing page and maybe
       in grid, but hidden by default;
       2. remove inability to delete system pages;
       3. add new permission named "Delete Protected Sections" (and check it for
       "root" user too);
       4. maybe in debug mode virtually give that permission to any user in
       administrative console;
       5. when user tried to delete protected section without proper permissions
       show him nice alert or red message above the grid, that "Protected section
       were not deleted" or something like that.

  2. I think that such fields should be visible & deleting such categories
    should be allowed in Debug Mode, not by permission. Site administrator
    (who in most cases logs in as root) shouldn't be able to delete
    protected content, but only developer.

    Also, may be we need to think about System field in grid and how to
    merge it with new Protected field functionality. For me, System field
    currently doesn't make much sense, but with Protected field nobody
    will understand what these two mean and what is difference between
    them. May be, we need to rename something: System - to Is Theme File,
    and Protected - to System. May be somebody has better ideas for

  3. By the way, is there a way to hide these "light red" system folder for admin
    (and root) users?
    Root user could still activate this view, but standard admin wouldn't be
    able to do so.

    For example, I have a customer who have many different theme files, and he
    don't understand why he have dozens of "_Auto: design/xxx" in his admin...

    2010/3/29 Alexander Obuhovich <>

  4. He probably have theme not compatible with 5,x release (like onlinestore
    theme now). He should add ".smsignore" file in each directory for each theme
    with ".*" in it. Then delete all "_Auto: ..." pages. Then press "Refresh" on
    "Themes" section. If he did all correct, then no new sections with red icons
    will be created.

    On Mon, Mar 29, 2010 at 5:23 PM, Phil ..:: ::.. <

  5. I didnt knew the use of this file, now it's done. Theme is a brand new one,
    coded by my hands from new Default.


    2010/3/29 Alexander Obuhovich <>

  6. In my previous post I forgot to mention, that after proper .smsignore will
    be added, then no "_Auto:" pages will be created on next theme scan.

  7. yes, it works :) thanks

    2010/3/30 Alexander Obuhovich <>

  8. Hi guys,

    Here are my thoughts on this:

    1. I think it's a good idea to change wording for System so it's more
    descriptive, how about "From Template" or "Template". I think 1st is
    more descriptive considering that column name is "Type".

    2. I would keep IsSystem and add Protected field, so it can be applied
    to ANY Section. In the end we'll have the following combinations:

    a. User and Protected (Yes)
    b. User and Protected (No)
    c. From Template and Protected (Yes)
    d. From Template and Protected (No)

    About why we disallowed Deletion of System sections for Users - I
    think the same reason we are having this conversation + it would keep
    growing the IDs.

    3. I would make ALL System (new Form Template) - Protected by default
    - so can't be deleted (if deleted still restored with Refresh in

    4. I would limit deletion of Protected to DBG for now and then we'll
    see if further break down on Permissions is needed. We should start
    thinking about simpling permissions


  9. Maybe that IsSystem field should be renamed to PageType with possible
    values: physical/real/template (1) and virtual (2) (we use that term a lot).
    Lets keep rule, that non-virtual pages (1) can only be deleted in debug mode
    and they have input box (not dropdown) in debug mode only, when developer
    can see actual physical template being used.

    If we rename IsSystem column this way, then it will make more sense without
    adding new Protected column. We can also show nice notice when user tries to
    delete non-virtual pages, like "It is forbidden to delete non-virtual

    Of course "non-virtual" term I used here will be replaced to proper wording
    from: physical, real, template.

  10. Hi Alex,

    Sounds like a good approach to solve the issue.

    In my opinion we should:

    1. Rename IsSystem column to PageType with two options:

    a. Template (since directly connected with template)
    b. Virtual

    Who else has an opinion on this (ie. Sergey) please post here!


  11. Also adapt code (if needed) to mark container pages created during
    "advanced" (can be any else theme) scan to be marked with "Template" type
    and will be working as usual. Other seems ok.

  12. Agreed!

    Sergey and others - would you please review our discussion and post
    your opinion in here since you were involved in the talk too.

  13. Two last Alex's posts make sense, I completely agree, but initial
    thread open reason stays unresolved: what should developer do when he
    wants to create default-design-type page, but this page needs not to
    be deleted (it may be used in any fixed link on site, for ex. Contacts
    link on every page)? We leave it as it is today - developer creates
    template with only one includу tag?
  14. No, he created pages manually (as before), but he specifies, that this page
    has PageType = Template (field editable only in debug mode).

  15. "PageType = Template" for page that is not template? This is unclear.
    Again, some option renaming may help. Or may be we should add one more
    option for type, such as Protected?
  16. As I've mentioned before:

       - PageType = Template: page, that uses physical template backend and
       therefore can't be deleted
       - PageType = Virtual: page, that uses common design template backend and
       can be deleted

  17. I think Sergey meant to say what about Container sections that are created
    whenever we scan the Theme and place Real Template Section inside Container
    ones - does it make sense to call them PageType = Template?

    Yes, I think so.

    The other advantage of Protected can be that we do NOT want Users to delete
    even some regular Sections (pages) - so structure is no broken.


  18. So what difference in code processing is between "Template" and "Protected"

  19. I guess Protected can be ANY Section (PageType = Template or Virtual)?

    It me it makes sense. For user it will apply to Virtual in most cases, why
    in Admin with DBG you can delete ANY section?


  20. So we are back to original post about creating new Protected (Yes/No) field
    plus renaming IsSystem to PageType.

  21. Dmitry,

    I'm only against making unclear things. Developers won't understand
    that page has type Template when there's no physical template for it.


    In my opinion, processing will be the same, except one thing: for
    Protected page user will be able change design (since it's virtual),
    but not for Template page.

  22. Hello guys,

    Sergey, I don't understand why you say there's no "physical template", as
    the virtual category is created when inportal finds a design. I've missed

    It seems we don't use the exactly the same terminology and thus we don't
    understand our thought :)


    2010/4/7 S.G. <>

  23. Ok for Dmitry's post.

    Phil, there 3 types of pages that can exist based on this discussion:

       - virtual - user adds manually and specifies design from dropdown (it's
       called "virtual" since multiple pages are using same design template);
       - template - is only added automatically during theme scan and nobody can
       change it's template (called "template", since it's only page, that uses
       given template in theme, which by the way is not design template); also that
       pages can only be deleted while in debug mode only;
       - protected - it's virtual pages + page can only be deleted while in
       debug mode only; and user can change it's design from dropdown.

    Seems, that we are moving forward to task creation.

  24. Alex,

    Thank for this clear explanation. Sergey said that users cannot modify
    "template pages"... but I do it everyday using "Design mode", where is the
    trick I didn't understoud?


    2010/4/7 Alexander Obuhovich <>