Search

The working groups have been toiling away and we’re happy to announce Symphony 2.2RC2:

If you’re using Git to test the default install, remember to use the integration branch of the workspace repo

As usual, please test thoroughly and report bugs. Developers, continue the fantastic work you’ve done thus far updating your extensions.

Big thanks to all who reported and squashed bugs in RC1.

I have one question:

Why are the system parameters sent to the frontend also in XML? They are already accessed in the XSLT through {$param}.

This is a good question. Twofold:

  1. #386 Sanitation issue with params swimming in the pool found that parameters containing apostrophes would not be rendered properly when the param is used in XSLT (e.g. $website-name). This is down to the way data is passed from PHP to the XSLT processor, and can be resolved by getting the content from XML instead
  2. Symphony 3 does not use params in this way (it may even not use params at all…), instead favouring this content going into the XML directly. Implementing this in Symphony 2.2 exposes developers to this early so it isn’t such an alien concept in the future

Aham, I understand. So, it’s time to move to XML params.

I’m missing a delegete to edit the form on the authors page.

Something like this on line 385 of symphony/content/content.systemauthors.php would do just fine:

Symphony::ExtensionManager()->notifyMembers('EditAuthorForm', '/system/authors/', array('form' => &$this->Form));

Not sure if EditAuthorForm is the most correct name to go, but I’ll let you decide. I requested this delegate earlier.

Is it too late to have this delegate added to S2.2? Or is there already another delegate that I’m not aware of (since most of the new delegates are not yet documented).

edit:

or even better (also provide an authors’ ID):

Symphony::ExtensionManager()->notifyMembers('EditAuthorForm', '/system/authors/', array(
  'form' => &$this->Form,
  'author_id' => $author->get('id')
));

I think you’ll be able to access the AdminPagePreGeneratedelegate to modify the page: check the page you’re on, walk the DOM tree until you find the elements you want to append to. You can get the author using:

Administration::instance()->Author;

This delegate would also help in my new Twitter Notifier extension, and I had noticed the request, so didn’t request it myself.

It’s a very ‘long way round’ without it to modify the Author pages…

I have a question…

Should the Configuration Class ‘set’ method expect either a string or array? It seems to only accept a string at present.

I’m trying to save a list of section IDs from the preferences page, and assumed (following an example from Nick’s Entity Diagram extension) that I could just pass an array. When I do, I get an error:

String expected Array given

from the set method at line 61.

…unless I’m doing something wrong…

I’ve seen other extensions just implode the array and save it as a string.

Nevertheless, there is a setArray function of the Configuration class.

Have a read of the inline code documentation, it may help :)

Yeah, I saw it but as it’s the preferences page that is saving the data and not me, I didn’t know how to invoke the setArray method. I’ve just followed how Nick has done it and I can’t see him imploding the array anywhere.

Anyhoo, I’ve added a function to the preferences Save delegate to do what you’ve suggested.

@nickdunn:

You can get the author using Administration::instance()->Author;

That gives you the ID of the current author who is logged in, not the author you clicked on for editing.

It’s a very ‘long way round’ without it to modify the Author pages…

I agree with designermonkey. Especially now when you have to retreive the ID of the user you are editing from the URL or something.

Please consider a delegate to add extra fields to the author page.

check the page you’re on, walk the DOM tree until you find the elements you want to append to.

I am trying to do this now, but the only way to insert a fieldset between te last fieldset and the last element (which is a div), is to loop through the whole form while creating a new one, insert the new fieldset before it reaches the last element (the div-element with the save-button), and replace the existing form with the new one.

But… When I try to assign a new form (XMLElement) to $context['oPage']->Form it still displays the original form. Isn’t $context['oPage']->Form overwritable?

What are other options to insert an extra fieldset after the the last fieldset in a form on the Authors create/edit-page?

I think I might have discoverd a bug here. If you try to change the $context['oPage']->Contents in the AdminPagePreGenerate-delegate, nothing happens! I mean, shouldn’t the following change the page:

public function screwUpForm($context) {
// Shouldn't this replace the contents on the page with a <h1>?
    $newForm = new XMLElement('h1', 'test');
    $context['oPage']->Contents = $newForm;
}

I attached a simple extension demonstrating in what’s in my opinion a bug. Place it in a folder called ‘screwup’ in the extensions-folder.

Attachments:
extension.driver.php

I think it has something to do with line 374 of symphony/lib/core/class.administration.php. I mean, shouldn’t $this->__buildPage($page); be called after the delegate call on line 386? Otherwise you can’t manipulate the DOM output (which is the case now). The Page->generate();-function on line 388 only sends out some headers.

Just ran into an issue with the "Cross-Site Scripting (XSS) Filter"-Extension.

In line 68 it prints out "FAILED" which causes a symphony warning when detecting malicious input:

Cannot modify header information - headers already sent by (output started at /Users/me/Work/Projects/example.com/www/extensions/xssfilter/extension.driver.php:68) /Users/me/Work/Projects/example.com/www/symphony/lib/toolkit/class.page.php line 72

Without this print "FAILED" everything works as expected.

Is this some intended behaviour I'm not getting or just some leftover debug code and should be filed as a bug?

Yeah, leftover code. Fixed in this commit.

@kanduvisla No, without the buildPage running, there is no $this->Page. Regardless, good spot on the bug, I’ve fixed it in this commit.

I’ve added AddElementstoAuthorForm delegate, containing $this->Form and the current $author object of the form, which closes #565.

Yippee!!! :-)

@brendo: Wouldn’t it be better if the delegate gets fired before the last div (with the actions) gets appended? Otherwise you can only append extra fieldsets after the save-button, which shouldn’t be the case.

I suggest to move the delegate to line 384 of content.systemauthors.php.

also, overwriting the form still doesn’t manipulate the page: The following rule in my extension still does nothing:

$context['form'] = new XMLElement('h1', 'test');

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