Lumberjack - customising the CMS side?

Add ons
1

I’ve ended up with many SS3 websites that use the old DOAP Module for better or worse. Kinda wishing I hadn’t used any modules what so ever now though.

The backed of DOAP used a Gridfield which you could customise nicely for end users. I’m struggling to re-create the usability once I’ve fandango’d the DOAP SiteTree split back over to normal Page Classes in SS4.

It’s a massive manual database ID matching nightmare to move from DOAP back to SiteTree. Especially if you have a lot of data to deal with.

Process rundown:

  1. Make new Page Classes to mimic your old DOAP setup. Same field names, etc. Get the DB working and the Templates up and running under a new temporary Parent menu Item.
  2. Copy DOAP and NewsItem (example) and SiteTree tables over to a new temporary database for modding. Add all of the unique fileds from NewItem into DOAP table then use a JOIN Update to bring in all the data from NewsItem into DOAP so it’s all on one ROW as you’re going to need to reindex the IDs.
  3. Find the last SiteTree ID.
  4. Reindex the DOAP table ID field starting from the next ID from SiteTree.
  5. Copy across the new NewsPage table from the new setup.
  6. Now carefully INSERT the fields from DOAP that match field names in NewsPage and to the same into SiteTree.
  7. Copy that all into SiteTree_Live as well.
  8. Don’t forget to manually set the new ParentID for the new NewsHolder page.
  9. Test it out in the CMS on SS4.

If the SiteTree is now huge. I have 180 News pages to deal with.

I have installed Lumberjack but I can’t figure out how to customise the CMS part to be more friendly to use. There doesn’t seem to be many options.

Is there a better way to customise the backend of the CMS in SS4?

Maybe a custom ModelAdmin for the NewsPage class? I’m off to try that now.

2

The ModelAdmin works rather well.

ModelAdmin picks up private static $summary_fields as they were setup anyway.

It’s kind of a shame then that Lumberjack doesn’t pick that info up.

At least it’s a suitable built-in core option.

Still a massive uphill task to re-integrate all the v3 DOAP setups back into SiteTree. Tough lesson learned.

3

You can modify Lumberjack’s Title and Gridfield config, though it seems to be undocumentd. If you look at the code you can find that you can overwrite lumberjack specific config in your managed pages.

It checks if your page has a method getLumberjackTitle() or getLumberjackGridFieldConfig(). With this you can make a lot of customisations.

Another solution would be to update the DataObjectAsPages module, cause the functionality should be the same and working with SS4. DOAP vs SiteTree is pretty much a matter of taste and reqirements.

4

Thanks, I’ll look into that.

I think use Lumberjack to hide the pages from the SiteTree visually. Then administer it for users through a ModelAdmin and it should be really intuitive for Admin users.

I’ve shifted it over to ModelAdmin I think it’s looking much better. The use of $summary_fields and custom getters is making it work really well.

I think the DOAP module should be left to die rather than be upgraded. Despite all the hard work it is to re-integrate the database. I guess it depends how many people were relying on it though. I know I extensively did so it’s an extreme about of work for me. Once I’m done though, at least I know I’m only using Core functionality and future updates shouldn’t break it.

I’ve only added Sortable Gridfield back in. Which was very easy to re-enable on the items I used it on. I think it should be added to core. It’s an essential function.

5

In SS3 I used CatalogManager for managing Pages in a ModelAdmin, cause Pages have some specialities that might break when using with a pure ModelAdmin.

It might be better in SS4, but I’d rather use a module that is specialized for managing Pages, aka versioned dataobjects with some extra functionality.

You can hide pages in the sitetree, Lumberjack does that and you can look at its code for how it’s done.

Both Lumberjack and ModelAdmin use a gridfield, that uses $summaryFields and can be modified very much. So it’s pretty much a matter of taste what you’ll use, if you need an extra menu button in CMS menu or if it should integrate and hide in the SiteTree.

6

Thanks, that’s great info.

I better check that ModelAdmin is saving versions. When I just tried the History tab on the Lumberjack view of NewPages it throws a “PHP Notice: Trying to get property of non-object” but that could be my fudging of re-integrating the data. The ModelAdmin version certainly can unpublish ok and re-publish though.

I don’t really need versioning for the project but also I’m not keen on breaking something that should be working so need to keep investigating.

I really hope I don’t need to use any additional modules. I’m anti-modules now. It’s difficult enough to get the normal DataObjects and Pages converted over to SS4 from SS3 never mind dealing with modules that may support NameSpacing or storing classes in /add/code or /app/src or /mysite or whichever one is in vogue for this week.

7

I did a quick test.

I added a new NewsPage via the LJ interface. That was versioned correctly. I changed the page in ModelAdmin and a version was correctly available back in the History tab on the LJ screen.

I just tried the opposite and it’s not working. I added a new NewsPage in the ModelAdmin and it’s not visible in the LJ interface. The page is displaying on the website though. Those added through ModelAdmin aren’t getting their ParentID set.

I’m filtering by Class on the NewPageHolder so it’s picking them up.

Thank you for the heads up. I’m still really evaluating how to move over from DOAP back to SiteTree. It’s a proper nightmare.

8

Versioning seems to be working fine from either method.

It’s the ParentID that isn’t set by the ModelAdmin method for new pages.

Thanks for the heads up on this. I could have really easily missed it.

I might look at how Uncle Cheese implemented his own non module DOAP and see if that is more compatible with my original SS3 structure just in case it’s a much quicker way to upgrade. Although the original DOAP added so much functionality like SiteMap support and MetaTags.

9

Back with an update on best way to migrate from DOAP SS3 to SS4.

I have implemented a version of Uncle Cheese’s Lesson about DOAP around the old News Page Item data from a DOAP. I converted the DOAP back into a normal DataObject and brought in the Content and Title fields via SQL.

This has worked really well. I haven’t re-implemented custom URLSegment management so just using ID for a /show/ID link to the page but it works fine. I could re-visit it later to re-implement that but I’ll be trying to avoid a DOAP style use where I can.

@wmk is absolutely correct. No DataObject that is in a $has_many link with a Holding Page should be administered from ModelAdmin.

There are two ways around this. One is to use the SinglePageAdmin module (which does not work with the latest version of SS4.2.1) which happens to be how I’d structured things in SS3.

One way is to simply not implement either end of the has_many link and then use the ModelAdmin in SS4. I was not using the direct ORM method to bring in the DataObjects on the page template because I was using embargo dates as a filter.

I also then enabled versioning on the DataObjects. This works fine for either a grid field or ModelAdmin implementation. It’s as simple as adding two lines of code to the DataObject then deb/build then duplicate EventItem into EventItem_Live and set the version field to 1 in both for all records. That will publish everything.

In my case I was just testing that implementation and reverted back to non versioned DO.

Feeling much more confident with SS4 now. It’s still a nightmare upgrading from SS3. I’m bringing one class at a time. It’s quite difficult when a page relies on six or seven separate DOs though.