Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Arantor
2416
Archived fixes / Re: Undefined: ex_string in Class-CSS
« on November 15th, 2012, 04:27 AM »
OK, now it's doing it every time I update the file.
Said file:
Code: [Select]
OK, so I figured out what the root cause it, though I have no idea how it manifests it this way. If you call add_plugin_css_file with a file that doesn't exist, it sort of chokes on it silently up until this point.
Basically, I'd managed to put add_plugin_css_file('Wedgeward:Calendar', 'calendar.css', true); because I'd forgotten about not needing extensions there.
Said file:
.calendar_table
width: 100%
th.days
width: 14%
td.days
vertical-align: top
.three-columns
box-sizing: border-box
vertical-align: top
width: 32%
margin: 0 .5%
display: inline-block
header .weekly
text-align: center
.weeklist
td
text-align: center
height: 49px
width: 7%
font-size: large
padding: 0 7px
td.weekdays
width: 100%
padding: 4px
text-align: left
vertical-align: middle
div.day
font-size: .9em
text-align: left
.event
color: #078907
.holiday
color: #000080
.chk
display: inline
float: left
width: 24%
padding: 3pxPosted: November 15th, 2012, 04:25 AM
OK, so I figured out what the root cause it, though I have no idea how it manifests it this way. If you call add_plugin_css_file with a file that doesn't exist, it sort of chokes on it silently up until this point.
Basically, I'd managed to put add_plugin_css_file('Wedgeward:Calendar', 'calendar.css', true); because I'd forgotten about not needing extensions there.
2417
Archived fixes / Undefined: ex_string in Class-CSS
« on November 15th, 2012, 04:19 AM »
Undefined variable: ex_string in C:\wamp\www\wedge\Sources\Class-CSS.php on line 800
Points to:
Code: [Select]
This came up after trying to load my calendar CSS file in the admin panel. I'd note that at no other time has it given me this error - including since I last changed it.
Points to:
// Did we finish the file with an extends or unextends...? Immediately open it and close it.
if ((strpos($ex_string, ' extends ') !== false || strpos($ex_string, ' unextends ') !== false))
$tree .= " {\n}\n";
while ($level > 0)
{
$tree .= '}';
$level -= $indent;
}This came up after trying to load my calendar CSS file in the admin panel. I'd note that at no other time has it given me this error - including since I last changed it.
2418
Features / Re: Calendar
« on November 15th, 2012, 03:26 AM »
Filter *what* by month? You can view the calendar by month...
I don't like the idea of scheduled tasks like that. Especially since the way holidays are set up, you can trivially make a holiday either be a one-off or recurring. Even SMF's is capable of that - for holidays that aren't on the same day each year, it creates a separate holiday for each instance.
Though, I might have something of an answer to the whole public holidays thing anyway... I'll keep you posted on this one.
I don't like the idea of scheduled tasks like that. Especially since the way holidays are set up, you can trivially make a holiday either be a one-off or recurring. Even SMF's is capable of that - for holidays that aren't on the same day each year, it creates a separate holiday for each instance.
Though, I might have something of an answer to the whole public holidays thing anyway... I'll keep you posted on this one.
2419
Features / Re: Calendar
« on November 14th, 2012, 09:53 PM »
Guys, guys, guys. Two works for you: SMF Calendar. It already has half of this stuff. That means I already have half this stuff.
Storing events? Check.
Events over multiple days? Check.
Events linked to posts? Check.
Placing it on the front page/info centre? Check. Even including upcoming birthdays and events if I remember rightly.
What it needs?
Recurring events? Hell yes.
RSVP to events? Yes.
Personal calendar... I'm not averse to the idea of personal events, but I'm not convinced it's a necessity. IP.Calendar has this (I think, the UI is much confusing)
Specifying time? Yes. Though, as IP.Calendar shows me, that raises other things itself.
Anything else?
Storing events? Check.
Events over multiple days? Check.
Events linked to posts? Check.
Placing it on the front page/info centre? Check. Even including upcoming birthdays and events if I remember rightly.
What it needs?
Recurring events? Hell yes.
RSVP to events? Yes.
Personal calendar... I'm not averse to the idea of personal events, but I'm not convinced it's a necessity. IP.Calendar has this (I think, the UI is much confusing)
Specifying time? Yes. Though, as IP.Calendar shows me, that raises other things itself.
Anything else?
2420
The Pub / Re: Practical plugins problem with WeCSS
« on November 14th, 2012, 05:21 PM »
I was going to get into a thorough explanation of the problem but I'm really not sure I care at this point. One of us, and I'm not entirely sure it isn't me at this point, has a fundamental lack of understanding in how WeCSS works especially with respect to plugins.
One of the problems, adding a simple CSS file from a plugin generates interesting filenames.
Like calendar-chrome24-member-m1-admin-local-global-replace-1352904776.css.gz and calendar-firefox16-guest-local-global-replace-1352904776.css (the only difference is the way box-sizing is expressed for Firefox's benefit), so we're already going to create a shit-ton of files from plugins, so the notion that 3 plugins each with their own stylesheet might generate 8 combinations is a silly consideration.
Sod trying to be efficient and not eat space, we might as well rewrite add_plugin_css_file just to add them to the main CSS file and be done with it because that won't be any worse than making a metric shit-ton of files how it is now.
One of the problems, adding a simple CSS file from a plugin generates interesting filenames.
Like calendar-chrome24-member-m1-admin-local-global-replace-1352904776.css.gz and calendar-firefox16-guest-local-global-replace-1352904776.css (the only difference is the way box-sizing is expressed for Firefox's benefit), so we're already going to create a shit-ton of files from plugins, so the notion that 3 plugins each with their own stylesheet might generate 8 combinations is a silly consideration.
Sod trying to be efficient and not eat space, we might as well rewrite add_plugin_css_file just to add them to the main CSS file and be done with it because that won't be any worse than making a metric shit-ton of files how it is now.
2421
The Pub / Re: Practical plugins problem with WeCSS
« on November 14th, 2012, 02:31 PM »Is that a problem? IIIRC, each variant is stored inside its own folder. Although, it'll mean many folders... what am I missing?
If you have 3 plugins that may or may not include their CSS on any given page, there's an on/off for each, so that alone will build 2^3 = 8 potential files - JUST for that, and that's before you multiply that by the number of variants there are.
What are the odds that people are going to have just 3 plugins?
Isnt it possible to include common.css in the CSS loader for your plugin? That's what it's for. If it first work then it's something I need I fix once I'm ready to get back to work.
Also, you can use mixes keywords if you don't want to extend. But there is no reason not to extend because it in it own CSS cache file anyway.
2422
Plugins / Re: Calendar
« on November 14th, 2012, 03:16 AM »
Why should we do anything when there are other systems out there that can do it already? Why are we developing Wedge when we can use SMF, which has a ton of themes and mods already?
Why the fuck should I worry about burning my free time on something that can be replaced by something 'better'? It seems like every way I turn, someone's recommending something 'better' that is a substitute.
Maybe I have a private community that I don't want (or can't be) shared with third party systems. Maybe it's for an intranet that doesn't have internet access. Maybe I care about my users' privacy enough not to force them into Google tentacles. Or maybe this is yet another sign that I should just fuck off out of trying to develop forum platforms and do something productive with my life, like writing games.
Why the fuck should I worry about burning my free time on something that can be replaced by something 'better'? It seems like every way I turn, someone's recommending something 'better' that is a substitute.
Maybe I have a private community that I don't want (or can't be) shared with third party systems. Maybe it's for an intranet that doesn't have internet access. Maybe I care about my users' privacy enough not to force them into Google tentacles. Or maybe this is yet another sign that I should just fuck off out of trying to develop forum platforms and do something productive with my life, like writing games.
2423
The Pub / Practical plugins problem with WeCSS
« on November 14th, 2012, 03:00 AM »
So I'm working on the plugin system and a problem hits me. I want to display three calendars in a row together at times. No bother, I thought, I seem to remember three-columns being declared for that, but it was obviously a long time ago because it's no big deal.
So, I thought, fine, I'll copy the definition for two-columns and adjust the width... except I can't, because you can't use extends in a plugin's CSS file to extend something in the main files. There's all kinds of good reasons for that, mostly that you don't want to potentially make exponential CSS files to cover for each combination of plugin where the files are loaded (three plugins will potentially generate 8 variations of everything)
That also rules out using inline-block as a base for extending (since that's what I really need here), so I figured I'd pull it in as a class, except I can't because it's defined as a virtual style (which means there's several loose places in the source where it IS used that need to be fixed)
Now, it's not a huge deal, I can use display: inline-block and only cut out IE6/7, and for a plugin I'm cool with that - but it does irk me that something that is in the core, I can't meaningfully use in a plugin. I also don't know how to get around it but I'm getting it out here in case someone does have an idea.
So, I thought, fine, I'll copy the definition for two-columns and adjust the width... except I can't, because you can't use extends in a plugin's CSS file to extend something in the main files. There's all kinds of good reasons for that, mostly that you don't want to potentially make exponential CSS files to cover for each combination of plugin where the files are loaded (three plugins will potentially generate 8 variations of everything)
That also rules out using inline-block as a base for extending (since that's what I really need here), so I figured I'd pull it in as a class, except I can't because it's defined as a virtual style (which means there's several loose places in the source where it IS used that need to be fixed)
Now, it's not a huge deal, I can use display: inline-block and only cut out IE6/7, and for a plugin I'm cool with that - but it does irk me that something that is in the core, I can't meaningfully use in a plugin. I also don't know how to get around it but I'm getting it out here in case someone does have an idea.
2424
Plugins / Re: Calendar
« on November 14th, 2012, 12:54 AM »
Your thoughts would also be appreciated in http://wedge.org/pub/feats/7698/calendar/
I wanted a place to centrally gather all the feature requests without it being like it's out already ;)
I wanted a place to centrally gather all the feature requests without it being like it's out already ;)
2425
OK, OK, don't get your hopes up. It's NOT going back in the core. NO.
However, while I let other things simmer until they're done, I'm curious to hear what people would like to see in the calendar.
I am not going to share what I have added or are going to add, but I do want to know what people think it should have. Remember, it's not a core feature, so the usual rules are less strict in this case.
It's basically that it needs some love and I feel in a giving-love kind of mood ;)
(I'm posting it here because I didn't want to get people thinking it was already out etc. because it's not.)
However, while I let other things simmer until they're done, I'm curious to hear what people would like to see in the calendar.
I am not going to share what I have added or are going to add, but I do want to know what people think it should have. Remember, it's not a core feature, so the usual rules are less strict in this case.
It's basically that it needs some love and I feel in a giving-love kind of mood ;)
(I'm posting it here because I didn't want to get people thinking it was already out etc. because it's not.)
2426
Plugins / Re: Calendar
« on November 13th, 2012, 07:54 PM »
OK, so you wanted an update.
It's very seriously nadgered by the way I just excised it from the core. While I dumped all the code into the plugin, I didn't exactly do it carefully, and I didn't realise how little of it really works.
Fortunately, I have a few things that need doing architecturally anyway with it, so it's not like I'm overly attached to its code and have no fear of breaking things :D
It's very seriously nadgered by the way I just excised it from the core. While I dumped all the code into the plugin, I didn't exactly do it carefully, and I didn't realise how little of it really works.
Fortunately, I have a few things that need doing architecturally anyway with it, so it's not like I'm overly attached to its code and have no fear of breaking things :D
2427
Archived fixes / Re: Embessing YouTube Videos in posts not working
« on November 13th, 2012, 06:57 PM »
What's in moderation filters?
* Arantor is willing to bet money this is not a bug.
2428
Features / Re: Plugin revs
« on November 13th, 2012, 06:44 PM »
(2 files, 2 KB)
Revision: 57
Author: arantor
Date: 13 November 2012 17:43:30
Message:
! [Calendar] Stupid typos I thought I'd fixed before last commit. (ManageCalendar.php)
! [Calendar] Fixing permissions up and some cleanup of the manifest. (plugin-info.xml)
----
Modified : /calendar/ManageCalendar.php
Modified : /calendar/plugin-info.xml
Revision: 57
Author: arantor
Date: 13 November 2012 17:43:30
Message:
! [Calendar] Stupid typos I thought I'd fixed before last commit. (ManageCalendar.php)
! [Calendar] Fixing permissions up and some cleanup of the manifest. (plugin-info.xml)
----
Modified : /calendar/ManageCalendar.php
Modified : /calendar/plugin-info.xml
2429
Features / Re: Plugin revs
« on November 13th, 2012, 05:57 PM »
Revision: 56
Author: arantor
Date: 13 November 2012 16:56:46
Message:
! [Calendar] Use the proper interfacing for member options, not the old old theme options. It might even install now, but still needs much more work. (ManageCalendar.php, plugin-info.xml, Calendar language files)
----
Modified : /calendar/ManageCalendar.php
Modified : /calendar/lang/Calendar.english.php
Modified : /calendar/lang/Calendar.french.php
Modified : /calendar/plugin-info.xml
Author: arantor
Date: 13 November 2012 16:56:46
Message:
! [Calendar] Use the proper interfacing for member options, not the old old theme options. It might even install now, but still needs much more work. (ManageCalendar.php, plugin-info.xml, Calendar language files)
----
Modified : /calendar/ManageCalendar.php
Modified : /calendar/lang/Calendar.english.php
Modified : /calendar/lang/Calendar.french.php
Modified : /calendar/plugin-info.xml
2430
Features / Re: New revs
« on November 13th, 2012, 05:12 PM »
(4 files, 1KB)
Revision: 1778
Author: arantor
Date: 13 November 2012 16:10:28
Message:
! Typo in paid subscriptions. (ManagePaid language file, possibly only English)
! Old calendar string left lurking. (Profile language file)
! The themes table must NOT have unsigned member ids, since we absolutely have to store -1 cases. No wonder member preferences and defaults are broken. (install.sql)
----
Modified : /trunk/Themes/default/languages/ManagePaid.english.php
Modified : /trunk/Themes/default/languages/Profile.english.php
Modified : /trunk/Themes/default/languages/Profile.french.php
Modified : /trunk/root/install.sql
Revision: 1778
Author: arantor
Date: 13 November 2012 16:10:28
Message:
! Typo in paid subscriptions. (ManagePaid language file, possibly only English)
! Old calendar string left lurking. (Profile language file)
! The themes table must NOT have unsigned member ids, since we absolutely have to store -1 cases. No wonder member preferences and defaults are broken. (install.sql)
----
Modified : /trunk/Themes/default/languages/ManagePaid.english.php
Modified : /trunk/Themes/default/languages/Profile.english.php
Modified : /trunk/Themes/default/languages/Profile.french.php
Modified : /trunk/root/install.sql