Thread

Wow, did my first site upgrade to 1.6 last night, and, as I had previously used Mark Huot’s Pages module on the site (now named ‘Tome’) it sure was an interesting upgrade experience. I’m sure I did a few things wrong (my mod_pages table went missing which broke things, so i had to put that back in there with a SQL query…), but I have another site to upgrade right now, so we’ll see if it goes smoother today than it did at 2 a.m. last night 😊

I have to say - the ability in the new Pages module to just give a static page any old URI is really pretty cool.

The Tome upgrade instructions on Marks’ site end with you (re)installing Tome to take the place of the original Pages module - but is this necessary? I now have 1st party Pages running, and Tome is installed as well. I’m pretty sure all I have to do to convert my original posts marked as Pages is go into each entry and enter it’s unique URI (making it a 1st party page by doing so), then delete the category for that page from the category group assigned to Tome. So, I’m slowly removing the static pages from Tome and converting them to EE-based static pages. Is this the correct process? Has anyone else been messing with the new EE Pages yet?

Just a couple other notes: It would be very nice if the EE Pages module replicated the CP layout of Tome as far as nesting the entries/pages (even if it is simply for visual organization) and the little icon that Tome uses for the Pages is a nice touch. There are also some Tome Plugins that allow for throwing out sets of links - is this something that we’ll no longer be able to do? Or can Tome be used in conjunction with EE Pages for visual organization and generating page-based links?

Should I just plan on eliminating Tome entirely and wait for some smart people to write a few EE Pages extensions and plugins that manipulate the CP layout and generate linkage?

One other thing as far as linkage that I didn’t immediately see: what is the variable for the Page URI? The static entry still has a URL title, but on some of my Pages I’m not using that, and I’ve cooked up a custom URI. OOPS… just found {page_uri} and {page_url}

Howdy—

That was a long message, but I think the gist of it is “will Tome and Pages work together?” - I don’t use Tome, nor its previous incarnation, so I can’t speak to it.  The plugins for tome will not work with Pages - however I suspect that there will be plugins made, rather quickly, for Pages as well.  That’s usually the way it goes with new modules after release, once the dust settles.

As far as display goes, if you have feature requests then please go ahead and carry on with the usual concept of posting feature requests.

@mdesign - The Tome and Pages module should work swimmingly together.  That said, you are correct, just go into each entry and enter the url for that entry, once you’ve done all your entries, just remove the Tome module and you’re 1st party all the way!

That’s what I thought, Mark, thanks.

I have more PayPal money coming your way :cheese: if you can whip together an extension that makes the 1st party Pages CP page look more like the Tome main CP page - nested Pages and nifty icons. I’m thinking that if there is a way to assign parent Pages, then a nifty little plugin/module could be written up to create subnav(s) and that sort of thing - similar to Tome’s plugins (static_tome_path, etc) functionality in a way. Thanks.

@mdesign - the idea is certainly circling around my head.  Though, as this is the first version of the module, it’s worth waiting a few revisions to see what the EllisLab team updates before hacking in my own functionality.

Hehe - I just wanted to make absolutely sure that this sort of thing is swimming around in your head! Or circling.

You’re right, the new 1st Party Pages module works just fine with Tome - but I’m wondering if, when I “convert” an existing Tome page to a new EEPage, if I should leave the page “registered” with Tome, or delete the category for the page from the category group for Tome.

If I leave a category for a converted page in Tome, but also have the entry as a new EEPage:

* segment variables are still hosed, meaning the ‘seg_’ array has to be added to path.php to access url segments
* I still have access to a couple variables like {static_page}, {static_page_level}, {static_page_name}, and {static_page_short_name} (although I’m not sure I necessarily need these at all or anymore, if I was using them)

If I delete the category for the static page from Tome, then I get to use segment variables again, I lose the other variables, and I lose that super nice hierarchical layout of the pages that my clients so love!

Hmm. Guess I wouldn’t need those variables to badly, now that I think about it. I should probably just step away from the Tome if possible…

A while back, I installed the Pages module, but didn’t end up using it. However, I then had some issues uninstalling it, which resulted in me having to remove most of it manually. Now I see when I look in the database (specifically, exp_modules) that the module is still mentioned there. Should I try to clear out all mentions of the module before upgrading to 1.6? And where else should I hunt for them?

@masuga - yup, i’d step away, you probably won’t need those variables once you move over to to the 1st party module
@Linda A - how is it mentioned in the exp_modules table?  the only other place it would be is in the exp_extensions table and the mod_pages table.

Its listing module id 31, module name Pages, module version 3.5.8 and has cp backend yes.

Hum, that’s an old version of Pages, you should be able to remove that prior to updating to EE 1.6

There’s no entry for it under Modules, though. Or do you mean just delete that line directly from the database? Basically, what happened when I tried to uninstall it was that I kept being sent back to the same page, with the module still installed, so eventually I tried removing the directory manually.

o, sorry.  yes, you should be able to just remove that line from the database as long as you haven’t updated to 1.6 yet.  also, as always when working in MySQL be sure to back up your database prior to doing anything.

I agree with the first post regarding visual organisation in tome.

the new pages module is ugly and much less intutitive than the tome module.
one of the main reasons i use tome is that my clients find it a much simpler and clearer way to view the structure of their site than the built in expression way. the new pages module needs the visual organisation and icons of the tome module. using page’s “company/info/about_this_site” is much less intutitive than tome’s visual hierarchy with icons. (- i suppose this should be in feature requests.. shame the ee people didn’t notice this clear usability advantage in the first implimentation of pages)

one thing not in tome that would be great is buttons/links that make it clearer what to click on to make a new post or to edit an existing one - ie. currently i have to tell clients to “click on the ‘x entries’ text to edit an exiting entry” and “click on the page name to add a new entry. - it would be great if this was clearer for my not so ‘not-so-computer-literate’ clients. - clearly labled buttons or links eg ‘edit existing post’ or ‘add new post’ would ease the confusion.

until expression engine adopts the more elegant execution of the tome module, i’ll be sticking with tome.

I second voodoo6 vote.

I’m stickin with Tome. The new module doesn’t look like there is even a way to setup and OUTPUT a navigation structure for your static pages. If I am not mistaken, all it really does is allow you to setup a custom URL. Your module, Mark, is much more functional and useful for clients. I wished they had used your blueprint and just enhanced the functionality and feature set. The EE 1.6 Pages module seems like a step backwards. But please, anyone correct me if I am wrong.