Search

@bauhouse, put an empty .gitignore file in the workspace/events directory :)

@buzzomatic

Tricky. I like it.

S3 is looking really good. I had no troubles installing it locally on my Mac. (Not running MAMP).

Thanks, @buzzomatic. I had in mind to add the .gitignore file, just ran out of time last night.

The reason I ask about the $current-page parameter is because the navigation.xsl utility needs to be modified to work in Symphony 3.0 anyway, replacing the page node with view in the XPath, and, in the match template for the view node, using the title node instead of name for the value-of instruction. Templates will need to be refactored anyway, so we might as well change $current-page to $current-view and $root-page to $root-view.

On another note, how difficult would it be to refactor the login info event from 2.0 for version 3.0?

On another note, how difficult would it be to refactor the login info event from 2.0 for version 3.0?

I imagine this will be re-thought a little, considering there is now a more comprehensive ACL involved — I don’t know if it will be a like-for-like port.

I guess that is getting closer to the point of my question: is it possible to use the existing ACL to handle access to front end views and forms?

Stephen, good point on the params. I’ll make sure we fix that.

It’s possible to get very close to what the Login Info event did just by creating a data source called “Login Info” that has “Users” as its source and filters the Username by {$cookie-username}. This will output the following XML:

<login-info>
    <user id="1">
        <username>bauhouse</username>
        <name>Stephen Bau</name>
        <email-address>me@example.com</email-address>
        <language>en</language>
    </user>
</login-info>

So, the only thing missing from the XML is the user role to be able to display front-end content based on the role of the logged in user. For now, you can do something like this:

<xsl:template match="data">
    <xsl:choose>
        <xsl:when test="login-info/user/@id = 1">
            <xsl:apply-templates select="entries/entry" />
        </xsl:when>
        <xsl:otherwise>
            <h2>None shall pass.</h2>
        </xsl:otherwise>
    </xsl:choose>
</xsl:template>

But it’s not yet possible to do this:

<xsl:template match="data">
    <xsl:choose>
        <xsl:when test="login-info/user/role = 'developer'">
            <xsl:apply-templates select="entries/entry" />
        </xsl:when>
        <xsl:otherwise>
            <h2>None shall pass.</h2>
        </xsl:otherwise>
    </xsl:choose>
</xsl:template>

Any ideas on how I can get the AAC extension to add the user role to the list of elements that can be included in the data source?

I’m guessing AAC would need to provide its own DS type.

@phoque, @bauhouse, thanks!

@craig, yup in nyc. would be great to meet up as well. email me - my user name @gmail.

Has installed Symphony 3 Beta. Worked well until I tryed to create a new section. I got this error:

array_merge(): Argument #1 is not an array

An error occurred in /(my-site-path)/symphony/lib/class.textformatter.php around line 30

* 25 $this->formatters = array();
* 26  
* 27 $this->formatters = array_merge(
* 28     glob(TEXTFORMATTERS . "/*.php"),
* 29     glob(EXTENSIONS . "/*/text-formatters/*.php")
* 30 ); 

Hope somebody can help me! Thanxy

@jensweigel - Welcome to the Symphony forum. I noticed you just started using Symphony. Just so you know the Symphony 3 Beta is still undergoing tons of changes is probably not the best for you to base a site on right now. Your best bet would be running off of the latest code on the Symphony 2 branch. That is the stable branch of code right now. Actually, I’ve found the best one branch so far is the integration branch of the Symphony 2 (which is currently at 2.0.8RC3). 2.0.8RC3 is very close to being final and is actually more stable (I find) then 2.0.7.

The Symphony 2 branch is very, very powerful. The Symphony 3 branch is a different beast altogether… it’s going to be awesome… but I think it would benefit you greatly to learn off of the stable Symphony 2 branch first. I hope that helps.

hmmm.. okay I guess you are right! Just thought to start with the newest symphony will be better because I read that it will change a lot …

Will wait for an Release Candidate!

@jensweigel - instead of waiting for a Release Candidate for Symphony 3, I think you should jump right into Symphony 2. It is really great system. That way, you can get the hang of templating with XSLT.

This is pretty much a question to the core team:

How do you want to transfer data within symphony? Do you want to use xml for all of this (for the sake of easy extensions), or should the basic php datatypes (array, etc) be used for this?

For instance, if an extension returns its delegates, it’s a php array, but if it’s loaded from the config, it’s in the xml format. Which one do you think is more desireable within symphony? In other words, should the xml be turned into an array after loading, or should an array be turned into xml?

A bit off topic, but just wanted to say how impressed I am with the 3.0 beta. Fantastic work!

I’ve got 3.0 beta running under Nginx web server on my VPS, I thought the vhost config (specifically the rewrite rules) might be useful to others. It’s working OK so far but no guarantee here!!

http://pastie.org/1042277

Anybody have this working on Webfaction yet? I received the same installation errors as @almacmillan but I haven’t looked into it much at this point.

Rob, sorry to be a noob, where would those rewrite rules go? Is that code something specific to the type of webserver?

Rob, sorry to be a noob, where would those rewrite rules go? Is that code something specific to the type of webserver?

Yes it’s specific to the Nginx (pronounced engine-x) web server. The majority of sites worldwide use the Apache server, but it’s not the only option and this one is gathering momentum because it’s light on resources and quick so ideal for small, cheap virtual servers from cloud providers like slicehost, rackspace, linode and many others.

The rules would typically go in a vhost file that would be located at, for example, /etc/nginx/sites-available/name.of.vhost.file (under debian-based linux distributions such as ubuntu) and then enabled by symlinking that file into the /etc/nginx/sites-enabled directory.

It’s perhaps all a bit beyond the scope of a forum post here but if you want to do any reading about server setup and management I’d thoroughly recommend that you visit articles.slicehost.com where there is a huge number of tutorials about setting up servers, securing them, installing the stack (web server, database and PHP or other language).

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