Content disappear after theme name change + Change theme name bug

[Phil -- wbtc.fr --]

Hi guys,

here is what's happening on a v510:

- change the primary theme folder name, and set it up again as primary in admin: the index page content (created using content manager) doesn't display anymore

- revert to original theme name, the content is still not displaying

Question: how to retrieve this content? (in another way than digging into DB)

Suggestion: we should have a button to populate new themes with content from another theme

+

Bug (tested on v512): in admin, edit a theme, in general tab change his name, save the change: this theme will have the same name as before, and is de-activated (red icon)

Then either theme name can't be changed here, and we should make theme name non-editable, or name change is buggy

Thanks for helping!

p

[Alexander Obuhovich]

Text, that you enter in content blocks is bound with current theme pages only.

This is done because same content blocks in another theme could be located in absolutely different places (or even missing) in another themes.

However virtual pages (pages, that you manually create in "Structure & Data" section) share content between themes.

In your case "home page" is associated with "index.tpl" template from you theme and it's content isn't shared.

--
You received this message because you are subscribed to the Google Groups "In-Portal Bugs Team" group.
To post to this group, send email to in-port...@googlegroups.com.
To unsubscribe from this group, send email to in-portal-bug...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/in-portal-bugs?hl=en.

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

[Alexander Obuhovich]

Ok, then what will be the interface for this populate functionality.

On Fri, Jun 24, 2011 at 2:19 PM, Phil -- wbtc.fr -- <ph...@wbtc.fr> wrote:

I've understoud this, and this is a powerfull concept.

But I still have my content which have disappeared after renaming the theme name forth and back.

And I still suggest a "populate content fields" in case the new theme is a new version of the existing one, you wouldn't like to copy/paste all your contents again!

2011/6/24 Alexander Obuhovich <aik....@gmail.com>

[Phil -- wbtc.fr --]

I imagine it as a new button in Themes list toolbar, with tooltip named "populate content from primary theme".

2011/6/24 Alexander Obuhovich <aik....@gmail.com>

[Phil -- wbtc.fr --]

I've understoud this, and this is a powerfull concept.

But I still have my content which have disappeared after renaming the theme name forth and back.

And I still suggest a "populate content fields" in case the new theme is a new version of the existing one, you wouldn't like to copy/paste all your contents again!

2011/6/24 Alexander Obuhovich <aik....@gmail.com>

Text, that you enter in content blocks is bound with current theme pages only.

[Alexander Obuhovich]

Not too flexible, since you need to perform 3 steps to copy data:

1. set source theme as primary
2. use copy data button
3. set new theme as primary

[Phil -- wbtc.fr --]

1 & 2 ok, but you may don't set new theme as primary, if you are still working on it for a future release :)

If we want a maximum of flexibility, we can add 2 checkbox on each theme line in list,, and we create 2 columns: "source" and "destination"

we check the boxes and click in toolbar "copy content".

Alternatively... an small ajax to ask with 2 dropdown "source" and "destination", which appears when we clic on the button.

I'd also suggest a warning when primary theme is set as destination, to avoid content overwriting.

Another toolbar button missing is "export content", to have ability to save current content :)

2011/6/24 Alexander Obuhovich <aik....@gmail.com>

[Alexander Obuhovich]

Alternatively... an small ajax to ask with 2 dropdown "source" and "destination", which appears when we clic on the button.

Dropdown menu (like, when new product is created) on that button with target theme list sounds good.

Another toolbar button missing is "export content", to have ability to save current content :)

Doesn't make sense without Import button. And database backup is better, then individual content backup.

[Phil -- wbtc.fr --]

Alternatively... an small ajax to ask with 2 dropdown "source" and "destination", which appears when we clic on the button.

Dropdown menu (like, when new product is created) on that button with target theme list sounds good.

nice idea! then checked theme is the source, and we click on the target in dd menu (or even just a list of themes with clickable names) - still need a warning when overwriting primary theme, in case of error OR mouse accident when clicking

Another toolbar button missing is "export content", to have ability to save current content :)

Doesn't make sense without Import button. And database backup is better, then individual content backup.

DAtabase backup is actually very slow, and not user friendly.

Additionnally, a DB backup keep all data together, while import/export content keep contents away from all other data :)

[Alexander Obuhovich]

I have new idea about this: keep track of theme add/delete operations, e.g.

Theme:

• ThemeID: 15; ThemeFolder: theme1; Added On: <date_time>; Deleted On: <date_time>; Actions: [Undelete ...]
• ThemeID: 1; ThemeFolder: theme1; Added On: <date_time>

This way user will be able to undelete accidentally deleted theme into other theme he already has.

[Phil -- wbtc.fr --]

actually, tell me if I'm wrong, deleting a theme only delete the DB entries, but leave the theme directory and files as it.

Deleting a theme deletes template caches, and contents.

Template cache is easily rebuilt when refreshing themes via toolbar dedicated button.

Then deleting and undeleting theme is finally all about deleting or undeleting content attached to physical theme directory. Isn't it?

2011/6/27 Alexander Obuhovich <aik....@gmail.com>

[Alexander Obuhovich]

I meant if user deletes a folder on disk, then we somehow will try to track that act and display it to user. Maybe we can keep Theme table record, but mark it as "deleted on disk". This way user still can access it's data.

Also maybe we should prevent theme deleting from database, when it's folder is still in place (since it will be scanned and added under different id).

Also we should make theme name read-only, since it must much a folder name on disk.

[Phil -- wbtc.fr --]

your ideas sounds good, but I still propose to separate theme management from content, for example giving the ability to import/export/populate content, and thus dissociate content from theme.

Actually we can easily play with lang packs, emails, themes, but no golbal management for content itself...

[Dmitry A.]

Guys, Alex,

Would you please outline your proposed idea once again here so I can fully review and give my feedback on it?

Cheers!

DA

[Alexander Obuhovich]

Problem:

Content block content from non-virtual pages is lost, when administrator renames theme folder on disk, e.g. from "advanced" to "advanced2" and then from "advanced2" to "advanced".

Why is that happening:

In-Portal looks for a new and deleted themes each time, when administrator visits "Themes" grid. For each of templates in a new theme corresponding section in "Structure & Data" grid is created. That section stores all content block data, entered on the page from that section.

When administrator visits "Themes" grid after each rename (see problem description) was made, then at the end "advanced" theme will have absolutely different ID and will be no longer linked with corresponding section in "Structure & Data" grid.

Fixing ideas:

• don't delete theme in database, when administrator deletes it on disk. just add new status, e.g. Enabled/Disabled/Deleted
• when theme folder reappears, then change theme's status from "Deleted" to "Disabled", but keep old theme's ID, used to link it with all content block data
• add AddedOn, DeletedOn columns to provide more info to administrator
• remove "Delete" button in "Themes" grid, since even after being deleted theme will be added again, since it's folder is still on disk
• provide ability to copy content block data from one theme to another theme (theme template structure must overlap)
• make "Name" field of the theme read-only, since new theme will be created anyway after existing theme name is changed

When (during theme scan) In-Portal discovers one theme deleted and one theme added, then consider this as theme rename and just rename existing theme in database.

--

You received this message because you are subscribed to the Google Groups "In-Portal Bugs Team" group.

To view this discussion on the web visit https://groups.google.com/d/msg/in-portal-bugs/-/vH3GyyUwdxMJ.

To post to this group, send email to in-port...@googlegroups.com.
To unsubscribe from this group, send email to in-portal-bug...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/in-portal-bugs?hl=en.

[Phil -- wbtc.fr --]

nice resume Alex.

I'll say that the 2 last points are the most important -not because I asked for them, but rather because if we can save the content, then deleting theme completely won't be a problem anymore, providing the fact we can restore the content.

Another thing: we don't need the saved content structure to overlap the theme's structure we want to restore to. If it fits, it's filled, otherwise we could just ignore orphan contents. This behavior is far more "usual" for a content/restore system ;-)

I don't like so much to keep record of deleted themes, as I don't see any interest to know that 3 years ago I've deleted theme "beta1"...

Avoid theme renaming is needed primarily because actually, the field is open but doesn't work at all (see previous post about that).

2011/7/5 Alexander Obuhovich <aik....@gmail.com>

[Alexander Obuhovich]

We can reuse "Delete" toolbar button to delete themes, that were deleted on disk already, then. This way, when administrator is 100% sure that he don't need any data from that theme, then he can delete it.

By overlapping I meant, that at least 1 template location in old and new themes match :)

[Phil -- wbtc.fr --]

great idea to separate disk deleting from db deleting! this would be a good security step.

sorry I misunderstood overlapping term :)

then it'll be easier without "keep records" features, right?

2011/7/5 Alexander Obuhovich <aik....@gmail.com>

[Alexander Obuhovich]

Keep records is easier. Then how would you select from which deleted theme (if you won't keep them) you want your data to be transferred to another theme.

[Phil -- wbtc.fr --]

as you want, but deleted theme was, in my idea, deleted for real when we use "delete" from themes grid.

we could restore content to any theme, no relying on theme name, we just try to fill content where it overlaps, right?

[Phil]

Problem encountered again in 520... Any final idea on how to fix it?

[Alexander Obuhovich]

Ping to Dmitry.

I've summarized my idea for you and yet no reply from you for 1.5 years.

On Thu, Oct 25, 2012 at 12:24 PM, Phil <ph...@domicilis.biz> wrote:

Problem encountered again in 520... Any final idea on how to fix it?

--

You received this message because you are subscribed to the Google Groups "In-Portal Bugs Team" group.

To view this discussion on the web visit https://groups.google.com/d/msg/in-portal-bugs/-/V5JEz1OQP0cJ.

To post to this group, send email to in-port...@googlegroups.com.
To unsubscribe from this group, send email to in-portal-bug...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/in-portal-bugs?hl=en.

[Dmitry A.]

Hi Alex,

Apologies for delayed reply!

I have reviewed suggested Plan of Action for this task and it sounds good.

Would you please fine a Feature request for In-Portal 5.3.0. I strongly believe it's a feature then a bug plus we have similar (Soft delete) feature scheduled for 5.3.0 too.

DA