51
mboyden
Re: JSCal2
  • 2010/7/7 4:15

  • mboyden

  • Moderator

  • Posts: 484

  • Since: 2005/3/9 1


there is the jQuery datepicker widget in the jQuery UI core.

I could likely commit some code related to this (and default/blank dates, too) if helpful.
Pessimists see difficulty in opportunity; Optimists see opportunity in difficulty. --W Churchill

XOOPS: Latest | Debug | Hosting and Web Development



52
mboyden
Protector Module in XOOPS 2.4.4
  • 2010/7/7 0:01

  • mboyden

  • Moderator

  • Posts: 484

  • Since: 2005/3/9 1


I'm finally upgrading to XOOPS 2.4.4 (from 2.3.3b) on a site and they are currently using Protector 3.41 (as are most of the sites I'm working with). XOOPS 2.4.4 contains Protector module 3.40 (slightly modified, as it says in the documentation).

I've done the upgrade and Protector 3.41 seems to be working. I've done a diff on the modified version and "slightly modified" is quite a number of files, mostly related to some preload stuff as well as "making it easier to use for a number of types of users".

Can someone explain to me an overview of what this modified version brings to the board? What are the reasons that 3.40 modified would be better than 3.41 (slightly modified version of 3.40, but differently).

I'm trying to understand at a high level what one is losing using the module developer's latest version and why one should use the core version.

Thanks!
Pessimists see difficulty in opportunity; Optimists see opportunity in difficulty. --W Churchill

XOOPS: Latest | Debug | Hosting and Web Development



53
mboyden
JSCal2
  • 2010/7/6 23:56

  • mboyden

  • Moderator

  • Posts: 484

  • Since: 2005/3/9 1


I'm finally working on a live site upgrade to 2.4.4 (from 2.3.3b) and the new version includes JSCal2 as a replacement to the original jscalendar date selector.

JSCal2 technically isn't free (although it is open source). There is an $80/site license for it (with some package deals) and I can't find any information related to it being free for certain uses (like non-commercial sites).

Am I missing something or did the JSCal2 license change since implementing it? If not, is there a reason that XOOPS is basing its core software on a for-profit script?

I know that jQuery is the future direction. Is there a reason we aren't using a jQuery calendar? They exist and I've put them to use, too.

Will 2.5.x have jsQuery replacing it? (I obviously haven't looked yet) or is it staying with this JSCal2? Either way for this site, they want it all FOSS as it's part of the organization's mentality, but there are some fixes in 2.4.4 they want.

I'll note, too, that in their theme, I'll have to figure out why it's not displaying properly themed -- probably some little trick to it I've not yet seen in the docs.

Thanks!
Pessimists see difficulty in opportunity; Optimists see opportunity in difficulty. --W Churchill

XOOPS: Latest | Debug | Hosting and Web Development



54
mboyden
Re: Automatic account expiry
  • 2010/7/5 1:03

  • mboyden

  • Moderator

  • Posts: 484

  • Since: 2005/3/9 1


The subscription module from Third Eye is a solid but simple module that generally does what it advertises - it allows manual or automated adding to one or more groups by way of a payment gateway (paypal, ccbill, payflow at this point) at which point their subscription will automatically expire at a set time (and/or automatically renew) and (through a cron job) expires the users and removes them from the group. They have more than one gateway. The free version uses a manual gateway (effectively invoiced, and/or manually addable).

I haven't tried or used Adhesion, yet, but looks to be useful as well.

Good luck!
Pessimists see difficulty in opportunity; Optimists see opportunity in difficulty. --W Churchill

XOOPS: Latest | Debug | Hosting and Web Development



55
mboyden
Re: multilanguage: Show Date and time
  • 2010/6/29 15:47

  • mboyden

  • Moderator

  • Posts: 484

  • Since: 2005/3/9 1


You can also use <{$smarty.now}> to get the current date/time stamp and you can use the smarty modifier "date_format" to change it on the fly, all without using PHP in your template.

More info on the smarty date_format modifier manual page.
Pessimists see difficulty in opportunity; Optimists see opportunity in difficulty. --W Churchill

XOOPS: Latest | Debug | Hosting and Web Development



56
mboyden
Re: Allowed memory size of 33554432 bytes exhausted
  • 2010/6/29 15:37

  • mboyden

  • Moderator

  • Posts: 484

  • Since: 2005/3/9 1


Voltan's suggestion works on some, but not on others. It depends upon your setup and whether or not the PHP installation on your server allows you to have a custom PHP ini. If voltan's suggestion doesn't work (as it wouldn't on our cPanel, suphp-based servers), then you may be able to have custom php ini file. How that is specified depends on your setup. You may also have to insert some other info in your .htaccess file for the custom ini and/or Voltan's suggestion to work.

Some quick searching on the web should help you through your particular installation.
Pessimists see difficulty in opportunity; Optimists see opportunity in difficulty. --W Churchill

XOOPS: Latest | Debug | Hosting and Web Development



57
mboyden
Re: Question about Login through user.php
  • 2010/6/26 20:18

  • mboyden

  • Moderator

  • Posts: 484

  • Since: 2005/3/9 1


There is no quick, simple, easy hack to this. However, it was built-in to XOOPS to allow module developers to do that, but it requires the module developer to set a particular variable before redirecting.

The function is redirect_header found in the include/functions.php file:

function redirect_header($url, $time = 3, $message = '', $addredirect = true, $allowExternalLink = false)

the passed variable $url is the one you are looking for. Realistically it should pickup the referring URL if none is passed. Unfortunately a lot of modules don't use this very well and just give you the home "index.php" page as passed. Sloppy, but done a lot

So, you'll have to find the instance in the code that does this redirect_header and then pull the current URL to pass as the $url.

Clear as mud?

BTW, many folk just add a login area to the theme and the URL ($url) that is passed in the form is the current URL. That way it times them right back to where they were. That code can be found on this site, too, of course, and is in a couple of the programmatic themes.
Pessimists see difficulty in opportunity; Optimists see opportunity in difficulty. --W Churchill

XOOPS: Latest | Debug | Hosting and Web Development



58
mboyden
Re: Onair 1.04 Review
  • 2010/6/23 21:46

  • mboyden

  • Moderator

  • Posts: 484

  • Since: 2005/3/9 1


Generally, when doing time relative stuff, calculations, etc., I've always found that working with unix timestamps works best because it is the absolute common ground for datetimes and then doing a final display conversion at the very end.

Because of the weekly schedule aspect to this, best would be to use either a Sunday midnight zero-hour for all, as Ghia suggested, or stick with the dayOfWeek and timeStamp, but I'd suggest a timestamp that is seconds from 0:00 of that day. I'm not sure either will be the panacea because of the cyclical nature of a weekly schedule and getting those upcoming events for "next week" as opposed to "next day".

For final timestamping, you can use the XoopsLocal::formatTimestamp code (as you did in some of it) so that the time is in website time (as opposed to server time which may be different, but both are set in the XOOPS settings).

Finally, pass both 12- and 24-hour formatted display into the templates and the config var and let the template decide which to display. There is less lines of code and only one additional executed line of code/event and by passing the other dayOfWeek and timeStamp as well one could actually do calculations and comparisons more easily in the smarty template code.

Some code:
// event is Tuesdays, 11:30 - 13:45
// pull from dB is:
$config = array('timetype' => 1); // 1 means 12-hour am/pm
$event = array('day' => 2, 'start' => 41400, 'end' => 49500);
$timestampToday = strtotime('midnight');
// for each event pulled from the query
$event['startUTC'] = $timestampToday + $event['start'];
$event['stopUTC'] = $timestampToday + $event['stop'];
$event['start12'] = date("h:i:s a",$event['startUTC']);
$event['start24'] = date("H:i:s",$event['startUTC']);
// other calculations, ordering, etc.
// then pass to smarty
$xoopsTpl->assign('config',$config);
$xoopsTpl->assign('event',$event);

<{if $config.timetype == 1}><{$event.start12}><{else}><{$event.start24}><{/if}>

But I then also have the UTC timestamps that could be used in a local display via jscript, and such as well. For that, too, passing the timezone offset of the server as a config variable would help, too. I did that for the backend/xml/rss code I threw at you via email.
Pessimists see difficulty in opportunity; Optimists see opportunity in difficulty. --W Churchill

XOOPS: Latest | Debug | Hosting and Web Development



59
mboyden
Re: Onair 1.04 Review
  • 2010/6/23 3:23

  • mboyden

  • Moderator

  • Posts: 484

  • Since: 2005/3/9 1


ghia wrote:Quote:
Why not simply using datetime or timestamp for the start and end time?

In short, because it's a weekly schedule where the same event occurs at the same time every day of the week, say 11:30a-1:45p every Tuesday, throughout the 24x7 week timeframe. Instead of entering it as a calendar event 52 times for an entire year, we just enter it once and it repeats each week.

So, your SQL select code upon brief inspection looks fine. But it's how to get the timestamps to be for that particular day because otherwise the select statement won't work. That's the tougher part. Dates and times are a little tricky, although I've got some good php functional code for that stuff that I've gleaned from the web, but it does really want things in gmt timestamps. But, it's a weekly schedule based on a specific timezone, that's why I suggested that stored times should be from 0:00 for the day which becomes fairly simple to convert into a usable timestamp on a weekly basis.

BTW, the SQL code could just as easily be an OR statement instead of a UNION which should be faster that a union of two select statements, but either way, the logic seems sound given the right data to base it on.
Pessimists see difficulty in opportunity; Optimists see opportunity in difficulty. --W Churchill

XOOPS: Latest | Debug | Hosting and Web Development



60
mboyden
Onair 1.04 Review
  • 2010/6/22 20:13

  • mboyden

  • Moderator

  • Posts: 484

  • Since: 2005/3/9 1


Latest Version: 1.04 | Website
Author: culex

Note: Feel free to read the Onair Module Notes as formatted on my site.

Summary
Onair is a module designed for one or more Radio stations, TV stations, or any organization with a regular schedule to publish their weekly schedule along with playlists. It has one block that will display the current program, host/DJ and related information such as playlists. Overall, an excellent but simple module. Currently, I'm still working to get our playlists stuff working so this doesn't focus on that issue, especially since I don't have examples for the formats. We're looking at scraping XML feeds into a database and working with it that way.

Features:
* Fields: Station, Title, Host, Day, Time (start/end), Description, Plugin, Stream
* Block: Now Playing/Coming Next (jquery/ajax block)

Installation
I've only done a fresh installation, although it was updated to 1.04 (from 1.03) early in my start of the usage. So, I did update it per usual module updating, and it worked fine. Installation is done normally.

Errors, Bugs, Defects
One quick comment related to issues I dealt with. Overall, I think this module would do a lot better if it were to measure time based in seconds from 12:00 midnight of the schedule's timezone. I thought that a lot of the time calculations would have been much easier and that my solutions were a bit of a kludge due to it.

Templates
The onair_index.html template is never used. The main index actually uses the onair_program.html template and defaults to the current day. I needed a page that showed the entire weekly schedule. So, I wrote a function and used the _index template. I'll note, too, that the onair_program.html template has some problems in the code that could result in badly formed HTML.

Edit Schedule Times Not Kept/Shown
When editing an existing schedule entry, it doesn't display the start/stop times as assigned in the database; it always shows 12:00 midnight (0:00) in both 12- or 24-hour format. I fixed this one. My general recommendation would be for the module to store data on a 24-hour format and then convert to the 12-hour format for display as desired. I think this would simplify a lot of code dealing with the times.

To fix, there were a couple of places. In the end, all I needed to do was this "simplification" edit to /admin/index.php lines 172-193 from:
// determine 12 hour Or 24 hour format time

if (onair_GetModuleOption('timetype')=='0'){

// Uses class to set 24 hour format
$edformstart = new onair_XoopsFormTimeEuro(_AM_ONAIR_START'oa_start',20);
$edform->addElement($edformstart);
$edformstop = new onair_XoopsFormTimeEuro(_AM_ONAIR_STOP"oa_stop",15);
$oa_start date('H:i:s'strtotime($oa_start));
$oa_stop date('H:i:s'strtotime($oa_stop));
$edform->addElement($edformstop);
}

// Uses class to set 12 hour format
else if (onair_GetModuleOption('timetype')=='1'){
$edformstart = new onair_XoopsFormTimeUs(_AM_ONAIR_START'oa_start',20);
$edform->addElement($edformstart);
$edformstop = new onair_XoopsFormTimeUs(_AM_ONAIR_STOP"oa_stop"15);
$edform->addElement($edformstop);
$oa_start date('h:i:s a'strtotime($oa_start));
$oa_stop date('h:i:s a'strtotime($oa_stop));
}
changed to:
// Start/Stop Time Display
$timearray = array();
$oa_end strtotime("23:59:59");
// determine 12 hour Or 24 hour format time
if (onair_GetModuleOption('timetype')=='0') {
    
// Uses class to set 24 hour format
    
for ( $i=strtotime("00:00:00"); $i $oa_end;  $i+= 900) {
        
$timearray[$i] = date('H:i:s',$i);
    }
} else if (
onair_GetModuleOption('timetype')=='1') {
    
// Uses class to set 12 hour format
    
for ( $i=strtotime("00:00:00"); $i $oa_end;  $i+= 900) {
        
$timearray[$i] = date('h:i:s a',$i);
    }
}
$edformstart = new XoopsFormSelect(_AM_ONAIR_START'oa_start'strtotime($oa_start), 0);
$edformstart->addOptionArray($timearray);
$edform->addElement($edformstart);
$edformstop = new XoopsFormSelect(_AM_ONAIR_STOP'oa_stop'strtotime($oa_stop), 0);
$edformstop->addOptionArray($timearray);
$edform->addElement($edformstop);

This also allows you to remove the onair_XoopsFormTimeUs and onair_XoopsFormTimeEuro functions in includes/classes.php which puts in an ElementTray layer that really isn't needed (and it wasn't work correctly either, and is 2 of the 3 classes in that file).

Alternatively, this below worked, too, (what I did before using the combined code solution above). In admin/index.php, edit lines 177-179 to be:
$edformstart = new onair_XoopsFormTimeEuro(_AM_ONAIR_START'oa_start',0,strtotime($oa_start));
$edform->addElement($edformstart);
$edformstop = new onair_XoopsFormTimeEuro(_AM_ONAIR_STOP"oa_stop",0,strtotime($oa_stop));
and lines 187-189 to be:
$edformstart = new onair_XoopsFormTimeUs(_AM_ONAIR_START'oa_start',0,strtotime($oa_start));
$edform->addElement($edformstart);
$edformstop = new onair_XoopsFormTimeUs(_AM_ONAIR_STOP"oa_stop",0,strtotime($oa_stop));

And for the Add New function to operate correctly, you have to also edit two other locations -- first lines 368-370 to be:
$signformstarteu = new onair_XoopsFormTimeUs(_AM_ONAIR_START'oa_start'0strtotime($oa_start));
$signform->addElement($signformstarteu);
$signformstopeu = new onair_XoopsFormTimeUs(_AM_ONAIR_STOP"oa_stop"0strtotime($oa_stop));
and lines 380-382 to be:
$signformstart = new onair_XoopsFormTimeEuro(_AM_ONAIR_START'oa_start'0strtotime($oa_start));
$signform->addElement($signformstart);
$signformstop = new onair_XoopsFormTimeEuro(_AM_ONAIR_STOP"oa_stop"0strtotime($oa_stop));

Another part of the issue was that the XoopsFormSelect call in the includes/classes.php file weren't used correctly. It is defined thusly:
function XoopsFormSelect($caption$name$value null$size 1$multiple false)
To fix, change lines 53 and 84 to:
$timeselect = new XoopsFormSelect(''$name$value$size);


Time Sorting 12-Hour Format
Sorting dates and times doesn't work right using the 12-hour version with am/pm. In the 12-hour preference (as used in the US), the information is written to the database in a text field of HH:MM:SS AP. But when sorting, since it's a text field, 01:00:00 AM comes before 12:00:00 PM, which of course isn't correct. Affects displays both in the user and admin sides. To quickly compensate, I changed the module to use the 24-hour preference and then when modifying the templates (as I always do to every module), changed the display method with Smarty.
Shows to/past Midnight

The module currently doesn't support shows that start before midnight and go beyond midnight. To compensate, enter the show twice, one to midnight (23:59:59) and the other from midnight (0:00) to when it ends.

The module sort of supports shows until midnight, however there is an error. When adding a show, it displays a midnight (00:00:00) end/stop time of 00:00:00. However, then it won't display properly (with the on-air info nor in the now-playing block) in the module because of how the between SQL query operates. So, it really needs an end time of 23:59:59. Fortunately, the edit function takes care of that properly setting the end time of 00:00:00 selected to be 23:59:59. Then it works as advertised.

I thought this would be a simple in admin/post.php, but I didn't find it, so since I have a work-around, it's working fine for me. But it does need to get fixed for the add subroutine.

Enhancement Requests
These enhancement requests and my solutions were reported to the author to use as they see fit, and I'll provide my edits and updates for their use in the next version (hopefully). I think they were additive, but I also wasn't dealing with more than one station at a time which could complicate things, I think, if used. I also reused the Station and Stream fields to be something else since we only had one of each (at least sorta, but it was nice to use the fields without rebuilding the module further). It would be nice, too, to have a set of extra custom fields, maybe 5 or so.

Admin Menu
The Admin Menu needs to stay at the top of the pages and generally the admin area needs to do a better job of telling you where you are.

Now Playing/Coming Up Block and AJAX
The block using jquery (and ajax) worked, but a couple of comments.

One, it had a system load that wasn't really necessary. It only needs to check once in awhile, not 2 http calls every 20 and 30 seconds (5 times/min/browser really adds up in terms of server loading). It should be max once/minute max or something and should instead only check every minute or so around the next schedule change and using ajax to obtain an XML object including ALL of the info in a single call including the system time, the station time, doing the math and only checking again near/close to the expected change.

Second, the jquery call, while to a current version of jquery, interfered with the call made originally in the theme and broke my other scripts and plugins since it loads on top of them. The script call should be done only if necessary (but I've not investigated just how to do that). I just removed the loading of the script in the template.

Also, because of the data, the block display changes sizes depending on the content moving stuff around on the page (but that can be fixed in CSS and templates); it's just that some users might not be capable of dealing with it.

The templates used in the AJAX calls were the file templates because of the way they were called instead of those in the database (you're using a custom set, right; if not you should as it makes it easier to control between updates). To fix, in onair_ajaxassign.php and onair_ajaxassign2.php change line 25 to call the template from the database like this: $tpl->display('db:onair_div1.html');

Therefore, I created a new setup for this block using AJAX and called it backend. It is actually an RSS feed in XML that can be used by anyone including the new code I created for the now playing block. I also wanted to configure the number of upcoming shows and how that is displayed. Also, if you'd like this data to be able to be used via RSS pulls on another system, then an AJAX call is appropriate. The current solution isn't XML- or RSS-based, but the one I created is.

Weekly Schedule At-a-Glance
We needed a weekly schedule to show at a glance. I created a page for this based on the main index that just pulled and displayed more of the schedule, not too hard, really, but took some time getting it to show well.
Overnight Schedule

The module doesn't appear to handle the ability to have a show that spans midnight. Also, the display block doesn't appear to handle that either. Continuing to investigate and figure that out. I'd also like the ability to deal with on-air/streaming aspects so that I can help users understand whether or not they will only get it on the stream and/or on-air. Nor does it allow the ability to go all the way to midnight (latest stop time choice is 23:45), although you can select 0:00. You can add two entries for this and then it works well, to a degree, but it's not clear on the schedule that it continues without putting more info in.

HTML Out of Functional Layer
This module has at least one place where HTML is embedded in the functional code. When working with things like images and linked images, this should be broken up and passed as object data to a Smarty template to allow template designers better control without having to go into the functional layer. It can be done, but it requires smarty regex usually.
Pessimists see difficulty in opportunity; Optimists see opportunity in difficulty. --W Churchill

XOOPS: Latest | Debug | Hosting and Web Development




TopTop
« 1 ... 3 4 5 (6) 7 8 9 ... 43 »



Login

Who's Online

187 user(s) are online (126 user(s) are browsing Support Forums)


Members: 0


Guests: 187


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Apr 30
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits