Search

A new Extension, “Page Fields” is now available for download. Comments and feedback can be left here but if you discover any issues, please post it on the issue tracker.

Okay, this is my first extension so hopefully it works okay!

From the README:

This extension aims to to improve the usability of Symphony and provide a simple way to associate developer-defined content blocks or fields for pages and simple interface to edit them.

Essentially, the developer can define a collection of unique fields for each page and the end-user is provided a simple interface to set the values for the fields. Each page can have a different set of fields. These values are provided as a data source for the associated page so that they can be accessed from the page’s xslt.

Under the hood this extension creates a special hidden section for each page that you specify page fields for. Because the section is only available through the added “Page Content” menu only one entry can be added to a Page Field section. This data is then made available to the pages xslt through a provided “Page Fields” data source that is automatically added to each page.

An example of where this functionality might be useful is where a specific page has individual elements that you want an author to be able to edit. You could, of course, create a standard section for this, with fields for each element, but then the normal admin interface will let you create as many entries as you like in the section. This isn’t really ideal and can be confusing so this extension hopefully improves the usability for this approach.


You can try out the extension from the Extensions direction or from: http://github.com/skeary/symphony-page-fields/tree/

Any comments, questions, issues etc let me know. I’ve also tried to document it pretty thoroughly in case you need to debug it or want to get some ideas from it.

Simon

This is a great idea! Thanks for putting this together. It sounds like this will be very useful.

Seconded. Fantastic idea.

Will be checking this out further. Great!

Thanks again for the extension.

However, I encountered one issue. When navigating to Blueprints : Page Fields and clicking on the link in the “Page Title” column for my Home page, the following URL results in a Symphony - Page Not Found error.

http://home/sym/test/symphony/extension/page_fields/manage/edit/1/

This link works fine:

http://home/sym/test/symphony/extension/page_fields/manage/

I am working on a virtual host on a Mac and installed Symphony 2.0.3 as a subdirectory (http://home/ is merely an alias for http://localhost/~username/). I created a single page: a Home page. I clicked on the “Create” Page Field action, then clicked on the “Edit” action to create two fields: a Title text input field and a Body textarea field.

The XML output looks like this:

<page-fields>
    <section id="7" handle="pfpfpfpf-home">pfpfpfpf Home</section>
    <entry id="6">
        <title handle="my-home-page">My Home Page</title>
        <body word-count="9">This is the body text for my home page.</body>
    </entry>
</page-fields>

The URL to edit the page content for the home page looks like this:

http://home/sym/test/symphony/publish/pfpfpfpf-home/edit/6/

At first, I thought this prefix was an error. But I see that the handle prefix can be changed in the /page-fields/lib/page_fields_defines.php file:

define('PF_SECTION_HANDLE_PREFIX', 'pfpfpfpf-');
define('PF_SECTION_TITLE_PREFIX', 'pfpfpfpf ');
define('PF_MANAGE_URL', '/symphony/extension/page_fields/manage/');

It might be good to have some preferences:

  • to change the menu item name from “Page Content” to something else, if preferred.
  • to change the section handle prefix
  • to change the section title prefix

Otherwise, the README file could mention that the prefixes can be changed by modifying the page_fields_defines.php file and the Page Content menu title can be changed in the extension.driver.php file on line 290.

// Add the "Page Content' menu.
//
$pageContentMenu = array(
    'index' => 10,
    'name' => __('Page Content'),
    'children' => $childMenuItems
);

Thanks for the feedback, bauhouse :) I’ve pushed a new version to github that hopefully fixes the problem with the links on the Page Fields admin page. The page title links should now go to the appropriate edit page admin page. I’m not 100% sure about the best layout for this page, or if it should really be integrated into the standard “Pages” admin page, so if you got any suggestions that would be great.

I’ve also added an option under the preferences page to edit the label for the Page Content menu item. If you’ve got a better default name let me know too!

I haven’t yet added a configuration option for the section name/handle prefixes as I’m not sure of the use case for changing them as they’re hopefully not really visible. I could be missing something though… When do you think it might be useful? I’ve added a note to the readme, as suggested, to document how you can change them if you wish.

Simon

I should probably also mention that the prefix etc it just a bit of a fudge to ensure that the section names/handles don’t clash with any sections that the user might explicitly create. It also means that based on just the section names the extension can tell whether a section is a “Page Fields” section or not. I just chose “pfpfpfpf” as I didn’t think anyone would ever use it!

The extension could store extra data in the DB to manage this information but it adds quite a bit more complexity and, to be honest, I think potentially would make the extension more fragile with respect to Symphony changes. As it stands, the extension makes no changes the database structure, which I think is a bit cleaner and safer.

Thanks, @skeary. That fixes that page title links.

One other thing in the README file: the directory name should be page_fields instead of pages_fields for the extension to work.

[INSTALLATION]

1. Upload the 'page_fields' folder in this archive to your Symphony 
   'extensions' folder.

And if installing from git, the directory will need to be renamed from symphony-page-fields to page-fields.

Thanks for adding the preference for the Page Content menu item. I like to keep these menu items as short as possible, so I might want to simply change the menu item to “Pages” or “Content”. Although “Pages” might be confused with Blueprints : Pages, anyone logged in as an Author user type would not see the Blueprints menu.

For the page_fields_defines.php file, I would probably just use this:

define('PF_SECTION_HANDLE_PREFIX', 'page-fields-');
define('PF_SECTION_TITLE_PREFIX', 'Page Fields: ');

Then, the XML will look something like this:

<page-fields>
    <section id="9" handle="page-fields-home">Page Fields: Home</section>
    <entry id="8">
        <title handle="my-home-page">My Home Page</title>
        <body word-count="7">The body text for my home page.</body>
    </entry>
</page-fields>

And links to the entry form would look like this:

http://home/sym/test/symphony/publish/page-fields-home/edit/8/

This would look less like an error, I think. The page handles should still be unique enough with this prefix. If not, there is the note in the README to make the handles even more unique.

I’ve uploaded a new 1.0.3 version that uses the page id rather than the page handle to map a page to it’s associated page field section. I realised that if the page handle changed then the linking would be broken :( As part of this I think I’ve also made the naming a bit cleaner. Now the XML will look something like:

<page-fields>
        <section id="35" handle="page-fields-section-66">PAGE FIELDS SECTION 66</section>
        <entry id="134">
            <atitle handle="a-title">My Title</atitle>
        </entry>
</page-fields>

This hopefully looks a little less weird. The publish url also now looks something like:

http://…/symphony/publish/page-fields-section-66/edit/134/

I also tried to rename the github repository from symphony-page-fields to page_fields as this seems to be more consistent with other extensions and should make it less likely to use the wrong directory name for the extension. github didn’t really like this so I’ve ended up with an orphaned extension “symphony-page-fields” that I can’t delete so have just resorted to creating the new repository called “page_fields”. Please use this!

If you have any more suggestions or comments let me know.

Simon

If you go to your repository’s edit section (by clicking on the Admin tab of your repo), you will find a delete link at the very bottom of the page!

@skeary: This is a fantastic extension!

However, at the moment there are lots of errors in the log like these:

WARNING: 2 - in_array() [function.in-array]: Wrong datatype for second argument in file /var/www/www.example.com/extensions/page_fields/content/content.manage.php on line 130
WARNING: 2 - DOMDocument::loadHTML() [function.DOMDocument-loadHTML]: ID fields[-1][location] already defined in Entity, line: 822 in file /var/www/www.example.com/extensions/page_fields/extension.driver.php on line 112

Can this easily be solved? Or is this related to the core? (I am using the 2.0.3 stable release.)

Hi michael-e,

That’s not good… I will take a look tomorrow evening and hopefully upload a fix.

Thanks for the report and glad the extension’s useful, Simon

@skeary

Thanks for this extension! It was just two days ago I was talking about this useful functionality to be implemented. Thanks

@michael-e

I’ve uploaded version 1.0.4 that hopefully fixes the problems with the warnings being logged.

I couldn’t reproduce the DOMDocument::loadHTML() error but the line in the log file above seems to suggest that the admin pages are not valid HTML. This is a bit of speculation but it could be another extension creating invalid HTML or perhaps we’re using slightly different versions of Symphony.

I am still getting the the error below logged when I view the Pages admin page:

21:53:18 > WARNING: 2 - in_array() [function.in-array]: Wrong datatype for second argument in file C:appsxampplitehtdocssymphony-2.0.3symphonycontentcontent.blueprintspages.php on line 93

This appears to be a problem in Symphony itself…

Simon

@Simon, I don’t really know the downsides of “deactivating” the error handling for a single process, like you did in the extension driver. But actually the extension runs very smooth now. I do not see any errors in the logs. (As far as I remember, the error you mentioned might be connected to a small Symphony bug which has already been solved on Github.)

Just a small thing: The version number is wrong (in the extension driver).

This extension will be very very useful, for many websites, and so it might even become one of the most widespread extensions out there. So I am wondering:

  • How future-proof is the extension, in your eyes?
  • Is it “production ready”?

Hi michael-e. Sorry for the delay in response. I’ve been a bit busy this week…

Thanks for the feedback. I’ll fix the version number and have a think about the disabling of the error handling again to see if there are any ramifications.

When putting together the extension I tried to make it as “safe” as possible and reasonably resilient to changes in Symphony. - The last thing you want is an extension that can corrupt your databass. To this end the extension makes no structural database changes and the sections that it creates are perfectly legal sections in their own right. In fact you can turn off the extension and the page fields section appear as normal sections and you can manage them, as well as edit their entries, in the normal Symphony way. So, I guess, if the extension ever breaks you can revert to dealing with the sections in this way. So at least from the persective of the stored data, I think extension is quite safe.

Where I had to do a few things that may be a bit more fragile was with the customisation of the admin interface. Although Symphony gives you quite a few delegates there a few areas of the admin interface where the only delegate you have access to is AdminPagePostGenerate. This basically just gives you access to the final admin page HTML so that you can process it in any way you like. The plugin uses this to, amongst other things:

  • Remove page field sections from the standard sections list page
  • Hide the section title and a couple of other field on the edit section page for page fields sections
  • Remove page field sections from the standard publish menu

Given the extension modifies the HTML it is built around the current Symphony admin page design. If this were to change substantially, or in particular ways, then this area of the extension would have to be updated. I don’t think this is ideal but short of more delegates in Symphony itself I don’t really know how else this could be improved. I guess this is also a bit of a limitation of the delegate approach employed by Symphony over other methods - it can result in needing a LOT of delegates.

Although the extension would need to be changed if Symphony changes as above it should hopefully be only fairly simple changes required and if you need to do this yourself it should be pretty easy to do if you know a bit of php. I’ve also tried to comment the code as much as possible and organise it so that it should be as understandable as possible.

Hopefully this goes some way to answering your questions on the maintainability and reliability of the extension. If you’ve got any more questions let me know….

Simon

Simon, thank you very much for your answer. Everything sounds very reasonable to me. Generally people should think twice before using extensions as powerful as yours, but now I see that the potential is much bigger than the remaining risk.

So thank you very much for this extension. If this is really your first one, it’s hard to imagine what your second one will be like…

Trying this out for the first time and I’ve come across a little bug. It seem the Page Fields extension removes the delete button from all the edit pages, meaning you can only delete from the list view.

@Makenosound: You are right. I posted this on the GitHub bug tracker:

http://github.com/skeary/page_fields/issues#issue/1

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