Modifying Seagull


How can I add PEAR packages?

You can add PEAR packages for using them in your own modules. Obviously all PEAR classes have to go in the PEAR directory (/lib/pear/). You can either use the PEAR package manager (many tutorials at PHPkitchen) or copy the file there yourself.

If you want to use the PEAR package manager you have to set the install dir:

pear config-set php_dir <your_path_to_seagull>/lib/pear/ 

Then simply install the PEAR-packages you want using

pear install <package>

Don't forget to reset your settings for php_dir after the installation.

So I want to uninstall some modules…

At the moment you can hide a module from the "manage modules" screen or really uninstall a module per hand. There will be a function for that soon.

cleanly remove

  • remove module's folders (modules/ and www/theme/default/ directories)
  • remove module's entry in 'module' table
  • remove module's database tables


  • remove module's entry in 'module' table

(Take a look at these two seagull-general threads.)

How can I change the User Module

Is it possible to change the user-settings easily? 
I mean I don't need the entries like Adress 2, Adress 3, State, Country 
etc. But I need some others, like occupation, website ...

The way things currently work, you can manually edit your 'usr' table and modify/add whatever attributes you want, regenerate DB_DataObjects from the Maintenance mgr, and everything will continue to work as normal.

If you create your own theme (make a copy of default, but have it include only files that are different from default, ie header.html, footer.html, etc) then upgrades should be quite painless. Only fields that are important not to change are usr_id, email and the FK fields.

Ideally we want to move towards pairing the usr table with a child 'additional_attributes' table so upgrades would be more flexible, this is on the radar for the future.

Front Controller

how is it supposed to deal with GET forms?

there's a few different approaches we've taken to incorporating FC into forms, it basically breaks down into these categories:

  • raw urls
  • javascript targeting

for something like <form action=""> we would do the following:

<form id="foo" name="foo" action="{makeUrl(#results#,#search#,#bar#)}" method="get" flexy:ignore>

this will produce an url as follows, when submitted:

this is a somewhat messy mixture of FC and conventional styles but anything passed in the format ?foo=bar becomes available in $_GET and is therefore usable by the script.

the second approach would be for select onChange events, we've used stuff like:

<select name="groupBy" 

How about arrays inside the form?

> For instance, an action link with this url:
> http://.../module/action/myaction/sth[]/5
> is considered invalid (FWICS the array
> is changed to a string: "sth=5" instead
> of "sth[]=5").
> Can anyone confirm it?

we have a basic level of array parsing working. using FC, PHP's magic GET/POST array parsing is no longer available and is mimicked in SGL_Url::dirify() and getVarNames(). Form elements like:

<select name="array[foo]">
<select name="array[bar]">

which would produce, once built up, a big url like:[report_id]/2/reportData[report_id]/2/reportData[organisation_id]/5/reportData[period]/today/reportData[format]/1/submitted/1/reportData[report_id]/2/reportData[organisation_id]/5/reportData[period]/today/reportData[format]/1/submitted/1''/

which is url-encoded to:''/

this format is currently supported, to get your reportData[]/5 to work would be a small job.

while we're on the subject of url parsing, i think google (naturally) are doing it best, they build form pseudo objects which look much easier to deal with on the server side:

<input type="hidden" name="creative.destUrl.protocol" value="http">

better mapping, no?

Modifying the Database

How can I modify the usr table to include some other biographical information?

I modify the Usr object/table with each new project, what's in the default distro is just a generic suggestion. People have asked if they should extend and override the UserManager and Register class, I would say no, it's not worth it, just modify your table accordingly and regenerate dataobjects if you use these.