CMS Made Simple Forums

Hello All

As you know I maintain (or tries to, at least) the Xinha module. This has proven quite difficult to complete mostly due to path-troubles, and I understand I'm not the only one with these problems resulting in various hacks like javascript correction of paths etc.
The sole cause to the trouble I think is the different focus'es of the admin and the user section and I therefore wondered if it was possible to maintain the root focus eventhough in admin, and I tried to hack a bit. In less than an hours work I got half the admin to work, including moduleinterface and theming, without leaving the root focus!
I use a simple admin.php?file=listcontent.php structure with some checks to prevent url-tricks. I also got my Xinha module to work perfectly, as all my relative/absolute bugs vanished into thin air!
Of course I would not suggest such a rather radical change just to fix my own small module-problems, so I thought about pros and cons for this change, and so far came up with this list:

Pros:
  - Same focus for admin and userside is easier to figure when doing modules which can be used from both "sides"
  - WYSIWYG-modules are FAR easier to get to work
  - WYSIWYG-modules are easier to get to work on client side also
  - We get rid of that odd include("../include.php"); etc. inserted everywhere across the admin-files
  - Admin-files still confined to the admin-dir, just called through /admin.php
  - Modules can be made more ready for a possible future rewrite of the admin as a module of its own
  - A lot of the changes can be made in existing system-functions hiding the change from most users/programmers.

Cons:
  - It requires fixes all over the admin-section (I'll gladly do it, it's quite easy)
  - It may require small changes in modules, but as long as the API-url-path-generating function are used most of if can be fixed centrally in the class.module.php file

That's what I came up with for the moment...

I know it's rather a large step, but I hope you'll consider it for post-0.12 pre-1.0 stuff. As for the admin-section itself, it should be rather straight-forward to do, and I'd be glad to do it all! The trouble is of course the modules, which all will have to be checked, though I think a lot will work "out-of-the" box!

Looking forward to hearing your thoughts, and please do not chop my head off if you think it's the dummest idea on the planet.

Best regards
Morten/Silmarillion

I'm not opposed to this idea at all.  In fact, why not take it a step further and run through index.php?  I guess my main question is how do you login to the admin the first time?

Anyone else opposed to this?  I can see an issue if you wanted to make the admin run through https (or worse, shared https), but for the majority of us, it's a non-issue.

What are other people's thoughts?

Hey, cool that head is still on! Running it though index is certainly also a possibility! As for the login I had no trouble with the changes I made. It still checks the login and redirects to admin.php?file=login.php in case of not begin logged in...

Sil.

wishy wrote: I'm not opposed to this idea at all.  In fact, why not take it a step further and run through index.php?  I guess my main question is how do you login to the admin the first time?

Anyone else opposed to this?  I can see an issue if you wanted to make the admin run through https (or worse, shared https), but for the majority of us, it's a non-issue.

What are other people's thoughts?

There nothing to hinder the precise names begin a config.php-var... Good idea!

Sil.

@patricia: it probably would help against automated attacks if the obfuscation was done at install time with some random string. but it should not be a substitute for real security.

The sole cause to the trouble I think is the different focus'es of the admin and the user section and I therefore wondered if it was possible to maintain the root focus eventhough in admin, and I tried to hack a bit. In less than an hours work I got half the admin to work, including moduleinterface and theming, without leaving the root focus!

Hi Sil, I'm new here, so please pardon while I try to understand.  What do you mean about "root focus"?  And would your proposed change affect anybody else's modules or plugins?

I've been working on modules that mostly provide admin-side features, so the way things work now (/admin/listcontent.php) is something I'm used to.  Are you saying that would be replaced with "/admin.php?file=listcontent.php"? What is the benefit to doing things that way rather than a direct URL?  Just curious.

Hi Sloop

What you describe below is one way of attaining what I proposed. Wishy is considering a slightly different method, but my main concern is that the root path should be the same when in the admin (now it's /admin/) and the userside (now /). The problem is that not all WYSIWYG-systems (at least not Xinha) behaves well when working with images, and other things needing a path, when you edit the page in the admin-root (meaning a picture gets a SRC like "../uploads/images/mypic.jpg") and the having to show the the content in the userside root (where the path from before is not valid). This means that if the wysiwyg does not support handling this issue, some dreadful hack is needed for fixing the paths.
I think you can rest assured that this is not a change made without a lot of discussion and consideration, but I wanted to bring up the issue while going insane trying to get the Xinha-module to work properly.

Best regards
Morten/Silmarillion

I've been working on modules that mostly provide admin-side features, so the way things work now (/admin/listcontent.php) is something I'm used to.  Are you saying that would be replaced with "/admin.php?file=listcontent.php"? What is the benefit to doing things that way rather than a direct URL?  Just curious.

Hi Sil,

Interesting.  I've got a closely related issue- I'm hacking admin to manage more than one CMS site.  Doing this by having a primary CMS installation that knows about other CMS installations on the same server, through a table containing some of the config.php values, the ones that indicate the db_name, db_prefix and the root path, and some others.

The issue is that CMS and admin currently point to only one database at a time.  My hack needs the admin code to point separately to the primary CMS installation, and leave $gCms->db to point to current site's config values.

My solution seems to be this: add a new var to $gCms, $gCms->dba, which would point to a separate ADOConnection just for the primary installation's database and document root.

This is a relatively simple change that could have a good impact - for sites that are using only one database and document root, $gCms->dba and $gCms->db would both point to the same database by both having a reference to the same ADOConnection instance.

I think this could be a helpful modification to CMS - the ability to separate the admin site from the actual site, internally, in terms of database and document root.  It would help set things up for version control and whatnot.

How would one go about requesting wishy and the development team to consider a change like this?

At this point, because it's so out of scope for what we're doing, I would suggest submitting a patch with the change already in it.  Though, there might be a better way to handle this...  Maybe I should have a method of people able to override the gCms object to allow users to implement their own methods OOP style.