sfClassicPlugin

[maarten....@rwo.vlaanderen.be]

Hi guys,

I've created our own theme plugin for ICA-AtoM 1.0.9 a while back. I've just tried migrating (which works beautiful btw), but I'm experiencing some issues with the sfClassicPlugin. ICA-AtoM keeps loading the plugin's css, even though I've disabled it using the admin interface. I'ts only a problem for a handfull of rules. Our plugin's stylesheets still get loaded last, so I could overrule those of the sfClassicPlugin, but I would prefer it not loading the wrong css in the first place.

Is this expected beaviour?

Kind regards and many thanks,

Maarten Vermeyen

[maarten....@rwo.vlaanderen.be]

Hi again,

I've clearly spoken to soon. This also happened in 1.0.9, so I'll just change my plugin to overrule.


Kind regards,

Maarten

[Jesús García Crespo]

Hi Maarten,

On Wed, Apr 20, 2011 at 12:45 PM, <maarten....@rwo.vlaanderen.be> wrote:

I've created our own theme plugin for ICA-AtoM 1.0.9 a while back. I've just tried migrating (which works beautiful btw), but I'm experiencing some issues with the sfClassicPlugin. ICA-AtoM keeps loading the plugin's css, even though I've disabled it using the admin interface. I'ts only a problem for a handfull of rules. Our plugin's stylesheets still get loaded last, so I could overrule those of the sfClassicPlugin, but I would prefer it not loading the wrong css in the first place.

I can't reproduce the situation that you describe. If I disable all the available themes here, only some Drupal necessary CSS files are loaded. I wonder if a bug in the forms is causing this error to you? User plugins selection is serialized and saved into MySQL q_setting table, what is your current value? You can try to get it running this SQL command:

SELECT setting.id, value FROM setting LEFT JOIN setting_i18n ON (setting.id = setting_i18n.id) WHERE name = 'plugins'

 

This is how it looks here after disabling all the available themes.

a:10:{i:0;s:12:"sfIsdfPlugin";i:1;s:13:"sfIsaarPlugin";i:2;s:11:"sfEacPlugin";i:3;s:12:"sfSkosPlugin";i:4;s:14:"sfIsdiahPlugin";i:5;s:10:"sfDcPlugin";i:6;s:12:"sfIsadPlugin";i:7;s:12:"sfModsPlugin";i:8;s:11:"sfEadPlugin";i:9;s:11:"sfRadPlugin";}

Well, you can overrule these CSS settings as you suggested, but I'd be pleased to write a fix if I find the problem and a solution, :).

Regards,

--
Jesús García Crespo,
Software Engineer, Artefactual Systems Inc.
http://www.artefactual.com | +1.604.527.2056

[maarten....@rwo.vlaanderen.be]

Hi Jesús,

I've tried it and it doesn't get loaded (I do get a null value for the 'en' culture, but there's a value for our default culture). As it turns out, it gets included in our own plugin configuration. We started out by overwriting just a few rules, but now our own stylesheet is serveral times bigger then the Classic one. I'll try to get rid of the dependency by the next release and clean up the css appropriately. When it works independently out of the box with cleaner css, I'll change the color scheme and share it with the community. Are their guidelines/coding standards for writing theme plugins and is there a community plugin registry for themes?

Kind regards,

Maarten

[Jesús García Crespo]

Hi Maarten,

On Thu, Apr 21, 2011 at 10:59 AM, <maarten....@rwo.vlaanderen.be> wrote:

I've tried it and it doesn't get loaded (I do get a null value for the 'en' culture, but there's a value for our default culture).

You may want try to update your default culture row value to:

a:10:{i:0;s:12:"sfIsdfPlugin";i:1;s:13:"sfIsaarPlugin";i:2;s:11:"sfEacPlugin";i:3;s:12:"sfSkosPlugin";i:4;s:14:"sfIsdiahPlugin";i:5;s:10:"sfDcPlugin";i:6;s:12:"sfIsadPlugin";i:7;s:12:"sfModsPlugin";i:8;s:11:"sfEadPlugin";i:9;s:11:"sfRadPlugin";}

So you get a free theme plugin configuration, that you likely want to update later. If you try this, please backup your db before any action. I don't know where the bug is, I have been playing for a while locally with different cultures, etc... but it works. If you want, send me your database dump so I can try to reproduce the situation and look for a fix.

 

As it turns out, it gets included in our own plugin configuration. We started out by overwriting just a few rules, but now our own stylesheet is serveral times bigger then the Classic one. I'll try to get rid of the dependency by the next release and clean up the css appropriately. When it works independently out of the box with cleaner css, I'll change the color scheme and share it with the community. Are their guidelines/coding standards for writing theme plugins and is there a community plugin registry for themes?

This is all the docs we have: http://qubit-toolkit.org/wiki/index.php?title=Theming

And you may want to see other site examples: http://www.ica-atom.org/doc/Examples

[maarten....@rwo.vlaanderen.be]

Hi Jesús,

The fact that there was a null value for the plugin configuration for the 'en' culture didn't seem to matter. I've made the necessary changes to our plugin and all seems in order now.

Since the local migration succeeded, I'll fire it up on our test-server tomorrow so I can test our IE7-stylesheets as well. If all goes well I'll migrate our production system next Wednesday.

Kind regards,

Maarten

[Jesús García Crespo]

On Thu, Apr 21, 2011 at 1:43 PM, <maarten....@rwo.vlaanderen.be> wrote:

Since the local migration succeeded, I'll fire it up on our test-server tomorrow so I can test our IE7-stylesheets as well. If all goes well I'll migrate our production system next Wednesday. 

Good job! Congratulations. I'm looking forward to see your migrated theme. Please, let us know when it is ready, :-).

Regards,

[maarten....@rwo.vlaanderen.be]

Hi guys,

We're now live with our ICA-AtoM 1.1 on http://archief.vioe.be.

Like the previous theme, it works for standard compliant browsers and we also support IE7 (no IE6). If you've visited before, you may have to refresh once.

I'll try to write up a report on our migration and give you guys some feedback.

[Jesús García Crespo]

On Fri, Apr 29, 2011 at 2:16 PM, <maarten....@rwo.vlaanderen.be> wrote:

We're now live with our ICA-AtoM 1.1 on http://archief.vioe.be.

Like the previous theme, it works for standard compliant browsers and we also support IE7 (no IE6). If you've visited before, you may have to refresh once.

Congratulations! This theme is lovely! 

I'll try to write up a report on our migration and give you guys some feedback.

Great, thank you. 

Regards. 

[Jessica Bushey]

Maarten,

The site looks great! I like your image placement in the descriptive record. 

A report on your migration would be great feedback - we look forward to it.

Jessica

Jessica Bushey, MAS

ICA-AtoM Community Manager

jes...@artefactual.com

Artefactual Systems Inc.

www.artefactual.com

--
You received this message because you are subscribed to the Google Groups "ICA-AtoM Users" group.
To post to this group, send email to ica-ato...@googlegroups.com.
To unsubscribe from this group, send email to ica-atom-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ica-atom-users?hl=en.

[maarten....@rwo.vlaanderen.be]

Hi Guys,

Here's an overview of the problems I ran into, but first some background info. We've been keeping up since 1.0.7 and went public in september 2009 with the 1.0.9 release, so our data has gone through some migrations already. I must say this was the smoothest migration yet. Since we're running on relative modest (virtual) servers, I've done the migration task locally. and then copied data over to the test server and production server.

Problems I ran into:

• "php symfony propel:insert-sql" gave a fatal php memory allocation error (while trying to allocate 39 MB or so on an 8 GB machine). Luckily the migration guide explained this was necessary to empty the database after the installer ran. So I've worked arround this:

1.  mysqldump with -d option: dump the schema
2. drop existing database
3. recreate database 
4. restore dump

• Had to apply the random slug patch
  

• Not all empty values in the database are NULL, there are some '' as well. This gives problems for some isset ($this-> ...) tests. Since i didn't know whether this was because of previuous data migrations, or that working in the new version would also generate some empty strings in stead of null values, I've modified the tests to ignore empty strings as well. At the moment this only seemed necessary in the Actor Detail template. I think this might be a VIOE issue, better solved by updating the database to eliminate empty strings, but as i said i don't know what new records will do yet.

• Also not all of our translations were in apps/qubit/i18n. This is probably due to the fact that we moved the application out of the web root, and made symlinks to the parts that needed web-access (and I might have forgotten to symlink this folder. They were however present in the i18n of the plugins, so we've migrated the plugins translations as well. Again I think this is a VIOE issue, and I just mention it here so others who might prefer to put no application code in the web server root, know this might be a problem. (I must say I wasn't happy when the www folder was dropped in 1.0.9, but I guess it wasn't maintainable with all the plugins ;-).

• I've also made some changes in the code to address our treeview sorting issue, caused by mixing identifiers with null values. This is very VIOE specific and already is reported as a bug. It is probably undesirable anyway to accommodate null-identifiers and identifiers at the same time, so I won't elaborate on this further.
  

All in all, a very smooth migration indeed. What worries me most is the Null vs. empty string problem, as I don't think this is a VIOE thing and impacts our data.

[Jesús García Crespo]

On Sat, Apr 30, 2011 at 12:22 AM, <maarten....@rwo.vlaanderen.be> wrote:

Not all empty values in the database are NULL, there are some '' as well. This gives problems for some isset ($this-> ...) tests. Since i didn't know whether this was because of previuous data migrations, or that working in the new version would also generate some empty strings in stead of null values, I've modified the tests to ignore empty strings as well. At the moment this only seemed necessary in the Actor Detail template. I think this might be a VIOE issue, better solved by updating the database to eliminate empty strings, but as i said i don't know what new records will do yet.

I think this problem is part of this issue,

http://code.google.com/p/qubit-toolkit/issues/detail?id=1120

David marked it as post-1.2, it must be a tough one, :-(

Thank you for your feedback.