Skinning and designing Serendipity (CSS, HTML, Smarty)
Stop your bitchin...... just write a novel by the time I return!!! hehehehe
Gotta few additional things in the works on the admin side, so I cannot send a version to you that is OK for the zipfile. Will try to do so in the next day or so pending input from Garvin on my latest suggestion.
I really hate going on vacation right now, especially with BP and 1.2 on the verge of release, but you guys are gonna have to get us there in the event I do not return in time.
Meanwhile, speak with Garvin and determine if he wants BP in the 1.2 release or would prefer it is simply another template in spartacus. An answer to that question will substantially influence our release schedule.
Suggestion for the coComment variable in the language files:
" Integrate coComment into comment form? For more information on coComment, visit http://www.cocomment.com"
I tried embedding it as a hyperlink and that does not seem to be allowed in these, even though it is in the main language files.
EDIT: I also suggest adding a little bottom margin to separate entries that might be posted on the same date, or grouped together as sticky:
Actually, Garvin sent me a comment on the lang files yesterday via email, so they will probably need some work anyway ...
All my core admin modifications are in this morning's svn, so get the latest snapshot!! I am going to take one more look at the admin template, then zip it up and email it to you shortly. Like I said - you will need the latest snapshot for it to work correctly.
EDIT: Updated zipfile emailed to YL to be included in next zipfile.
YellowLed brought to my attention a problem with the advanced types plugin/media option type. It's a typo, I'm afraid.
The problem is that the "height" attribute for the header preview div can be empty. On line 115 of the plugin's serendipity_event_advtypes.php, or line 623 of include/functions_plugins_admin.inc.php, you can see that I check to see if the template author set the $preview_height, and set the wrong variable ($preview_img_height) with a default of 100px if it's empty.
While we could fix this by removing the height attribute from the div, that would cause large images to be fully displayed, which has been a problem in the past. Instead, if you just replace preview_img_height with preview_height, you should get the expected preview div.
I've already fixed this in the SPARTACUS plugin baseline, and it should be in the next update in 24 hours or so. For users of the 1.3 baseline, or whichever baseline already had the 'media' option type, you'll either have to download tonight's nightly or make the change directly on line 623 of include/functions_plugins_admin.inc.php.
Sorry for the inconvenience.
Hmm. I don't really understand all that technical stuff, I'm afraid. Is this going to be fixed in s9y 1.2?
No problem, thanks for chiming in that fast, Jude
Let me go check the blog... 1.2 isn't out yet, hmm? That must be the SVN trunk, then. It should be fixed in the nightlies (for the daring) and the next release of 1.2. Users of 1.1.4 and previous versions will need the updated Advanced Types plugin from SPARTACUS instead.
Nope, it isn't, but as far as I know, the nightlies are already being generated from a 1.3 svn trunk ..? This is a little confusing ... well, never mind. Bottom line: If it doesn't work, get the latest advanced types plugin, period. Thanks again, Jude.
Hi guys! I'm back from vacation! Well, sort of. My availability is not quite what is usually is for the next few days, but at least I am partially back while we scramble for our final changes prior to the 1.2 release.
Thanks for looking into that height issue. I only had time to briefly mention it to YL via email prior to vacation, so I am happy to see you both jumped on it so quickly. The change is definitely NOT reflected in the latest 1.2 svn can you get that backported Jude?
Next - looks like YL has added another entry to the docsite, which is great. Unfortunately, I edited the entry to correct an error, and it is now set to draft. This seemed odd to me.... I corrected a few things in some other entry of YL's a week or so and it did not set it to draft for that one. Hmmm.... Is this normal?
I'll get back to that admin entry I have drafted when I have enough time to think about it.
@YL - where is the latest BP zipfile? Since the filename now changes with the date (a good idea), we no longer have a fixed file name.
Finally - I need some input from both Dave & YL so I know you are satisfied with the current admin template's appearance. The last revision I made included adding a more 3 dimensional appearance to things and I never received any input on that. I might tweak something minor between now and 1.2 release, but it would not likely be major.
No. Also, some of the entries now show up multiple times. I guess it's time to get this updated to the latest 1.2 beta ... however, I have deleted the redundant draft entries and set the entry on the customizable navbar back to "publish".
Well, there haven't been many changes in the past couple of days. Also, I figured there won't be many changes anymore with the pending release. That's why we have officially gone beta
This now includes your great admin template, but I have opted to set the fluid version as default. Simply seemed to make more sense since it fits into any browser window. Also, I have finally gotten the chance to test bp in an IE7, and guess what? It needs the same fix as IE6, go figure! So ie7.css is back. This also has the changes to the lang files and config.inc.php Garvin requested. Yes, it has lost some weight, but not any functionality. You will also notice (at least I did on my test server) that the theme options now load faster, so don't grouch
Satisfied??? That's the understatement of the year. It might very well produce some controversy (i.e. some people will find it too "modern" or "colorful"), but it's definitely awesome. I also sent a copy of bp-beta2 to an accessibility expert I know, and although the jury's still out on accessibility, he almost freaked out about the theme options and the admin template
So here's what I'm thinking: No more changes (to frontend and backend) unless some evil bug comes up. No additional features unless the accessibility expert finds out something really important. Instead, everybody should concentrate on writing documentation entries to the doc blog. I will probably focus on doing rather general overview entries. I think it's better to first cover those and get into the details later. You will probably focus on entries on the admin backend, which is fine. I don't know about Dave's availability, I haven't heard from him for some days.
I'm probably out for tomorrow, but I will have plenty of time for this starting Sunday. Oh, BTW: Good to have you back (more or less )!
Still not sure what is going on with the docsite. My user level is 0, but I belong to the administor group!!!! I also no longer see you or Dave listed in the user list, so something is definitely messed up - either just with my info, or perhaps the site as a whole. To avoid causing any problems, I am not going to make any changes, including to my own entries, until this gets resolved. Suggest one of you guys get the doc site upgraded. It would be nice anyway because we could then run the admin template (as well as the colorsets) through a validator.
Anyway - I see the changes to the language file. I think the one that is most likely to cause confusion is the dateformatting. Although I never liked the ones "viklund long" and "viklund short" (a user has to know there is a popular template viklund), the rest of the date formatting was fairly obvious. Now, it is not at all obvious and they are forced to look to another website for explanation, which is going to be intimidating to a number of people. If it has to remain, then so be it, but that one is worth contemplating further.
I am not so sure I agree on the fluid template as default. I understand the logic as I had considered it myself. However, the reality is that the fixed width looks great at 1024 x 768 (the most popular resolution), and even at 1280 x 1024, which is what I use. While I was able to produce a fluid width that looks VERY similar to the fixed, the fixed version uses graphics that simply cannot be used in the fluid version - graphics *I* (the dude who designed the thing) prefer!! Funny enough, at 1280 x 1024, I actually think the fluid version is a bit TOO wide, because there really is not that much content to any particular admin page, and it is only a single sidebar. I have also addressed the 2 different versions in my draft entry on the docsite, including their differences, relative advantages/disadvantages, and how to switch versions.
I see you also copied the style_fluid.css to style.css, meaning there are actually 3 stylesheets at the moment. Thought we were trying to cut down on storage??? Anyway, let me think about this issue for a few days. I did notice a missing semicolon in the fluid one just now, and there is a subtle change I want to make to one of the buttons, so I'll send you updates to both those files later. Also something I want to look at graphically in IE6, but something tells me I'm screwed due to PNG behavior.
There is one other frontend option that I COULD add if we want it. It is definitely going into my grey version, as well as what will likely come first - a frontend that matches the backend.
Anyway, something that personally drives me nuts is a homepage, with dozens of lengthy entries, and when I get to the bottom of a really long page, there is no further navigation except for next/previous page when what I am looking for is the main site page navigation (ie, identical to either the banner sitenav, or sidebar sitenav). Under these circumstances, I need to scroll all the way to the top of the page again, then select what I really want. I don't even like "top of page" links as much, so I created something in one of my "drawer templates" that has an admin option to "Also show navigation links at page bottom?" (yes/no) which then displays small text links (with the "current page" class stuff) below the footer. As I said, I will add this to any derivative I do for BP, so the question is do we want it in BP? If so, I will happily modify index.tpl and supply the css I have in mind (again - very unobtrusive, not like what we are currently using for site and sidebar nav in the colorsets).
Finally - I just checked the latest svn and see that Garvin backported Judebert's fix, so thanks Garvin (and of course Jude for doing it in the first place).
No prob. And thanks, Garvin -- I'll figure out how to check out branches in SVN someday. Since I'm using it at my job, it should be someday soon...
I'll see what I can do. I'll probably not get than done before Sunday or even Monday - work and a big town festival this weekend, sorry.
You're right, but this is really eating up performance. The real pity is that it's not possible to make that link clickable. I talked to Garvin about that - impossible. Another option would be to explain those date formats in a doc blog entry.
Personally, I don't think it's that much of a hassle to look up what these variables mean. Another option is to simply try it, but I guess we'll go with a doc blog entry - maybe simply some examples? - on that.
Alright, back to fixed.
No, I didn't. Did you maybe extract it to a directory where style_fixed.css and style_fluid.css existed before? Because in my working directory, there's only 2 css files in the admin/ dir ...
Got it. This has to be the last change for admin template, at least for this version of bp. I'm serious, we have to stop making changes to this and start writing documentation, especially since we're one man short. And I don't want to spend the night before release adding "just another little feature" or something ...
Alright, hand it over. I also suggest we add a theme option to (de)activate this.
Latest snapshot: http://www.yellowled.de/tmp/bulletproof-beta3.zip, which is basically beta2 with the updated admin template.
That fluid_fixed must have been leftover from something I was toying with.
Anyway, do YOU personally prefer the fluid over the fixed??? Maybe it is because I have dozens and dozens of hours into subtle little issues that makes me extremely aware of the differences, and more likely to prefer the more detailed fixed version (crisp outlines in the banner, infopane, footer, outside shadow, etc). Hell, I just moved one of the icons down 2 pixels this morning!!! Talk about anal!!! LOL!!!
I'll add this footer nav thing. Will probably position it below the footer for starters... we can move it to be within the footer if we want, but something tells me it will look better below. It will, regardless, have a admin option to disable/enable.
Other than that, I agree on the docsite stuff. Right now I cannot publish any entry!!!!!! Only choice is draft, even though I am a member of the admin group. Wanna poke around inside the database and see if you can determine the cause simply by comparing each of our respective settings?
The date stuff cannot be THAT big of a performace hit!!! Especially after all the other explanations were removed. In a situation like this, where it is REALLY not that obvious, my instinct says to go with the version that makes it REALLY obvious despite the micro performance hit. Even using YY-MM-DD directly in the config.inc.php could be better than what we have. EDIT: I saved your latest as beta2a locally.
IMHO, using "DD-MM-YY" is no better than "%d-%m-%Y". At least the latter has a clear documentation what "DD" or "YY" means.
It makes the language files much more clearer to read, is less maintenance and has less impact on the performance. Remember that those variables get parsed even if a visitor only comes to the blog. Every constant less counts! Especially if you want bulletproof to be used for virtually every s9y template.
Who is online
Users browsing this forum: No registered users and 1 guest