Search

What happened to the auto-detection of extension class names? I really liked the fact that the name of the class was determined by the extension name, thus making them very consistent..

But therein lies a problem. If the extension classname + folder name is not perfect, the extension is not visible to Symphony. In Symphony 3, the folder can be whatever you like and the class in the extension.driver.php file can be anything you like. Just make sure to return the classname at the bottom of the file.

Why are fields included in the section editor when they are not yet installed?

That would be a bug.

In the user roles, is it possible to limit access to a specific field in the section aswell? This would make this even more powerful!

There are currently no plans to implement such granular permissions. That’s not to say it won’t happen, but at this stage, it isn’t likely. However, there is good news. The author access control layer is an extension, so you could either tweak it to suit your needs, or roll your own version/replacement which has the specific requirements you need.

In Symphony 3, the folder can be whatever you like and the class in the extension.driver.php file can be anything you like. Just make sure to return the classname at the bottom of the file.

Don’t you think this will introduce other problems? Two folders with the same name cannot exist, but two classfiles with the same name, in different folders can. Creating all sorts of weird errors (cannot redeclare class, etc)

However, there is good news. The author access control layer is an extension, so you could either tweak it to suit your needs, or roll your own version/replacement which has the specific requirements you need.

This is really good news! As it will then offer most of the functionality I have needed so far, I think I will.

Why are fields included in the section editor when they are not yet installed?

That would be a bug.

Fixed.

I hope that you’ve sent a pull request?

I’m still working on more bug fixes before sending pull requests.

There are quite a few other things I would have done differently;) What would be the best place to discuss those, do you think?

Github I’d suggest, since Symphony 3 will be in a constant state of flux throughout its development. It will be very confusing for new users if S3 code/concepts are discussed here before S3 is nearer a release candidate.

I’m relatively new to github, where can we discuss code/concepts?

At the bottom of each page when viewing a file I think there should be a comments box. And they recently added the ability to comment on specific lines I think.

Hmm, the comment box isn’t there for me.

Also, some of the concepts I’d like to discuss are really about the entire project, and not really about a single file/line.

Is it possible to setup a forum/discussion platform on github?

Best keep it locked down to this thread then. Perhaps the guys disabled commenting while they develop ;-)

Yeah, I guess so ;)

Either way, to start the tech discussion: the thing that surprised me the most was the extensions class. The class itself is more like an extension holder/loader class than an extension definition.

What I would suggest, is splitting the extension class into two parts, an extension loader, and an extension class.

The loader class makes sure every extension is loaded correctly, and can return properties of multiple extensions.

The extensions themselves should not be given this functionality, and should be extended by individual extensions. The extension class itself should get functionality like enable, disable etc.

This way, a lot of nasty workarounds currently used can be avoided.

(I guess the same argument goes for datasources/fields aswell, but I didn’t dive into that deep enough, yet)

Really, really cool indeed! I thought Symphony 1.x was pure perfection, but since I saw Symphony 2.x coming I knew that it was. For the 2nd time, you proved me wrong, doh! :)

I’ve made this suggestion privately to Craig, but if S3 is moving to a model where an extension’s folder name is not a static thing (which is a very, very good thing IMO), then we need some way within an extension to resolve the current extension’s URL and path dynamically.

Hard coded paths in PHP apps and scripts have always made me a bit cranky.

@tony: I think having a very strict naming scheme prevents a lot of issues later on. Ofcourse those scheme’s should be coded the “right” way (no hard coded paths, using defines only).

What are your main concerns about fixed names?

Static folder names != strict naming schemes.

I think having an agreed naming scheme is a great idea, and hopefully we’re seeing the start of that with the beta.

I don’t think it’s a good idea to rely upon filesystem representations for validation (which is what happens in S1/S2) - the lack of flexibility means rewriting code if I ever wish to rename my extension, or it’s folder.

I think we’re saying the same thing, I just want the core product to provide some means of dynamically resolving my extension’s URLs and paths at runtime.

the lack of flexibility means rewriting code if I ever wish to rename my extension, or it’s folder.

I disagree with you here. If you choose to rename an extension in v3, it saves you 1 (one!!) name to change (the classname). I do not consider that to be rewriting code.

What I meant with a naming scheme, is a rule like: “class.namehere.php contains a class named namehere.” Those rules are standard practice.

The benefits of using such strict methods are huge: the classname follows from its filename, so a lean and bug free algorithm is easy to write. The more flexibility you add in the naming case, the more flexible the algorithm becomes, making it more error prone.

Also, how often do you rename an extension? More often than you would write one? Because in the current way of handling extension classnames, one line per extension has to be written EXTRA, to specify the classname. This sounds like a reversed world to me (making things that never happen quicker, but things that happen all the time less quick.. why?)

I think perhaps I haven’t explained this very clearly.

One of the things I quite often need to do in my extensions is load resources (JS, CSS, et al) into the active page (usually a backend admin page) - each time I do this, I need to hard code the folder name and path into my extension, like so:

Administration::instance()->Page->addScriptToHead(URL . '/extensions/ckeditor/lib/ckeditor/ckeditor.js', 200, false);

I’ve asked that there be some nicer, more dynamic way of resolving those URLs so I can say:

Administration::instance()->Page->addScriptToHead(this->currentURL() . 'lib/ckeditor/ckeditor.js', 200, false);

That’s definitely going to save me time rewriting code and worrying about having to change my code should I update folder/extension names.

There already is. (assuming you call that function from the extension.driver.php file).

You could use dirname(__FILE__) to get the dirname of the current file (in this case, the extension folder). Ofcourse, this could/should be added to the main extension class, if that’s what you mean?

On webfaction I get a 500 error when i try to install. The logs say:

[Fri Jun 18 08:17:39 2010] [error] [client 77.94.232.40] malformed header from script. Bad header=Content-Type: php52.cgi

But after some struggling, I removed the third line from the end (591) of install/index.php:

 $Document->Headers->render();

Now s3 is installed, and I am very happy:)

I agree with Tony AND Dutch here… Extensions so far have been left up to the developer as to how they are named and how files are located in them.

Agreement with Tony is that they need to have a set naming convention, which is in no way related to the foldername of the extension. Because of the way most extensions are stored on GitHub, we always have to manually rename the folder when downloaded. I can’t count the times I’ve seen someone reporting on this forum that they can’t activate an extension, and the answer being to rename the folder. It’s a bad way of coding doing it this way.

Agreement with Dutch that there are current ‘best practices’ for locating files, but until the API docs are written, developers are unaware of this. I’m looking forward to the official documentation on development for Symphony, and willing to wait until the core team are in a position to do such.

If we had a moderated wiki in place, maybe the dedicated community could start this process?

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details