rvm_css (v1.2)

ruud · 2009-11-13 19:43:19

Can’t hide the preference, because it’s something the user has to be able to change.
Apart from 1 comment, it doesn’t seem to bother anyone.

thebombsite · 2009-11-13 23:42:24

No Ruud, I meant with Stef’s plugin, if your plugin has been removed, you could hide the preference but as you say, it’s really not hurting anything to be there. Seems a bit of a waste of Stef’s plugin just to hide it.

Bloke · 2009-11-13 23:57:22

thebombsite wrote:

you could hide the preference

OT: When plugins are removed they can (more easily as of 4.2.0) clear up after themselves if the author wishes. But it’s not mandatory and is sometimes a good thing to leave prefs behind. Some people just prefer to keep a tidy house, so if a plugin doesn’t delete its own prefs, smd_prefalizer can help you seek and destroy any left luggage. No hiding, just good old-fashioned, unrecoverable deletion. Once you’re done zapping prefs you can even delete smd_prefalizer if you wish. I could probably do with making the docs a bit clearer actually. Next rev, promise!

And now we return to our regular rvm_css broadcast…

MattD · 2010-09-17 23:21:27

Just realized I didn’t have this plugin working because I hadn’t created the css directory. Now that I have my css files are coming out wacky. What did I do wrong?

ruud · 2010-09-18 12:59:09

I see a few extra line endings (no problem, really), but I suppose that’s how it’s stored in the database as well, since rvm_css doesn’t edit the contents of the style sheet; it just stores it as-is in a static file.

MattD · 2010-09-19 07:24:39

Strange, From my office, where we have IE, I was getting garbage. Looks good from here at home. I’ll have to see how it looks Monday.

MyOtheHedgeFox · 2010-11-06 18:58:28

Erm, will this plugin work correctly with TxP 4.3.0?

Last edited by MyOtheHedgeFox (2010-11-06 19:07:07)

ruud · 2010-11-07 18:56:54

Yes, since version 0.5 the plugin is prepared for TXP versions that do not store CSS in base64 encoding in the database.

MyOtheHedgeFox · 2010-11-08 15:21:02

Then the only problem is “n” attribute used by txp:rvm_css. =)

maverick · 2010-11-08 16:33:17

For those who hate to wait :D

This fixed the “n” attribute issue for me:

Edit the plugin. Find:

extract(lAtts(array(
    'format' => 'url',
    'media'  => 'screen',
    'n'      => '',
    'rel'    => 'stylesheet',
    'title'  => '',
  ), $atts));

change to

extract(lAtts(array(
    'format' => 'url',
    'media'  => 'screen',
    'name'      => '',
    'rel'    => 'stylesheet',
    'title'  => '',
  ), $atts));

ruud · 2010-11-08 18:13:48

If I were to change the plugin that way, it would break existing installs that still use the ‘n’ attribute ;)
Sticking with ‘n’ isn’t a problem.

Bloke · 2010-11-09 11:59:50

ruud wrote:

Sticking with ‘n’ isn’t a problem.

For now… but the css($atts) call on line 39 might cause problems in future TXP versions as it triggers the deprecated warning when passing n to the function.

Just off the top of my head (largely untested), can it be approached this way:

14a15,20
>   if (isset($atts['n'])) {
>     $atts['name'] = $atts['n'];
>     trigger_error(gTxt('deprecated_attribute', array('{name}' => 'n')), E_USER_NOTICE); // optional
>     unset($atts['n']);
>   }
> 
18c24
<     'n'      => '',
---
>     'name'   => '',
23c29
<   if (!$n)
---
>   if (!$name)
27c33
<       $n = safe_field('css', 'txp_section', "name='".doSlash($s)."'");
---
>       $name = safe_field('css', 'txp_section', "name='".doSlash($s)."'");
31c37
<       $n = 'default';
---
>       $name = 'default';
35c41
<   $file = $rvm_css_dir.'/'.strtolower(sanitizeForUrl($n)).'.css';
---
>   $file = $rvm_css_dir.'/'.strtolower(sanitizeForUrl($name)).'.css';

There’s probably a neater method if this eventually becomes desirable / necessary.

ruud · 2010-11-10 23:47:53

Version 0.6 released. See topic start for changelog and download link.

MyOtheHedgeFox · 2010-11-11 12:33:39

Thank you very much!

Bloke · 2010-12-08 11:14:31

Many thanks for the update Ruud.

Is it just me or does anyone else get a couple of warnings under 4.3.0 (debugging mode) when using the name attribute:

Notice: Use of undefined constant txp_version - assumed 'txp_version'  on line 45
Notice: n attribute is deprecated  on line 63

My stab in the dark seems to be that txp_version is only defined on the admin side so trying to test it elsewhere fails. Quick and dirty solution is to alter line 45 from:

if (version_compare(txp_version, '4.3.0', '>='))

to:

if (version_compare(get_pref('version'), '4.3.0', '>='))

But maybe it’s just me?

Last edited by Bloke (2010-12-08 11:15:36)

Textpattern CMS

Textpattern CMS support forum

#106 2009-11-13 19:43:19

Re: rvm_css (v1.2)

#107 2009-11-13 23:42:24

Re: rvm_css (v1.2)

#108 2009-11-13 23:57:22

Re: rvm_css (v1.2)

#109 2010-09-17 23:21:27

Re: rvm_css (v1.2)

#110 2010-09-18 12:59:09

Re: rvm_css (v1.2)

#111 2010-09-19 07:24:39

Re: rvm_css (v1.2)

#112 2010-11-06 18:58:28

Re: rvm_css (v1.2)

#113 2010-11-07 18:56:54

Re: rvm_css (v1.2)

#114 2010-11-08 15:21:02

Re: rvm_css (v1.2)

#115 2010-11-08 16:33:17

Re: rvm_css (v1.2)

#116 2010-11-08 18:13:48

Re: rvm_css (v1.2)

#117 2010-11-09 11:59:50

Re: rvm_css (v1.2)

#118 2010-11-10 23:47:53

Re: rvm_css (v1.2)

#119 2010-11-11 12:33:39

Re: rvm_css (v1.2)

#120 2010-12-08 11:14:31

Re: rvm_css (v1.2)

Board footer