Thread

I’m concerned about the non-standard, non-approved, non-supported way that eeSiteKit handles nested URI’s. What happens when EE 2.0x hits the streets?

Honestly, I don’t see any problem arising from this - but of course I’m not the developer. Looking at the source of eeSiteKit, every URL handling seems to be done by checking URL segments with {segment_x} and conditionals. If that would break with EE 2.0, I’d be in trouble with a lot of my sites even so they do not use eeSiteKit. If I recall correctly, there is even a FAQ entry or similar at eeSiteKit.com that mentions that even if EE 2.0 would break something, they would provide a solution for this.

In addition, I’m not so sure everyone will switch to EE 2.0 fast - looking at the economy, the fact the EE 2.0 upgrade will cost money and require additional work/learning, the delays in the EE development, the fact that right now no groundbreaking new features are announced (CI will be great to have, but not for existing, “standard” sites) and that EE 1.x will be supported for some more time. And there is the education factor: MS users might want to wait for SP1, Mac users will at least wait until EE 2.01 😊

Regards
Markus

And there is the education factor: MS users might want to wait for SP1, Mac users will at least wait until EE 2.01 😊

soooooooo true

Can’t speak entirely for Kurt as I only developed the installer and not eeSiteKit’s template system.  But he designed it specifically so that it only used genuine EE code.  If EE 2.0 is going to stop parsing {segment_x) variables than probably every site I’ve ever built is going to break.  I can’t imagine why EllisLab would do such a thing.  I wouldn’t worry too much about it breaking.  And if it does, I strongly suspect Kurt will come up with a reasonably easy fix.

Jamie

Having come from both a front-end design background, and an MS Access database background, my current sites in EE are becoming quite elegant and simple for fairly complex uses. I wish I could have learned all this stuff quicker, but once I let go of “this is a CMS” and really thought of EE as database design which you then iterate into your HTML layout with templates, things suddenly got a lot easier.

Now, I spend extra hours at the forefront thinking about my structure, while at the other end designing the site as I want it to look with no restrictions really…and then put the two together. Thinking structure out ahead of time (mapping it out several different times and ways) saves me hours of twiddling on the front end of things.

Of course, plugins and extensions like Gypsy and Playa make building structure even more elegant and fast.

I’m concerned about the non-standard, non-approved, non-supported way that eeSiteKit handles nested URI’s. What happens when EE 2.0x hits the streets?

We were concerned about the transition to EE 2.0 also, and that’s why everything in eeSiteKit is pure EE template code. There are zero hacks, zero custom queries, and zero additional add-ons (no modules, plugins, extensions or other “scripts”). We think this just might make eeSiteKit the single most EE 2.0 prepared 3rd party EE app. on the market. (well maybe the tag module should be included too. If my memory serves me, Paul prepared it for the transition last year and blogged about it.)

eeSiteKit’s non-standard way of handling nested URLs offers developers a functional nested URL structure without sacrificing the use of EEs powerful Categories system. This is something that is very difficult to accomplish with the traditional implementation of EE and is one of eeSiteKit’s strengths.

The only approval we’re seeking for eeSiteKit is the approval of the developers and designers using it and we do support this product and its methods in our support forums.

Also, my firm is building and maintaining dozens of sites based on eeSiteKit, so we have a significant investment in how well those sites will transition into EE 2.0, and every release after that. If EE 2.0 breaks something, we’ll be all over it until we have things restored.

- Kurt