Read this and other useful hacks at http://www.peak.ne.jp/xoops/modules/xhnewbb/viewtopic.php?topic_id=271&post_id=1062&order=0&viewmode=flat&pid=0&forum=1#forumpost1062

Lots of stuff to check out and cool hacks, so instead of double-posting it here, check it out at the home of piCal.

Yeah, still working on the graphics. Photoshop guru I am not. Also still evaluating xcGallery and MyAlbum.

Yet Another XOOPS Site To Review...

This is a demo site that I set up so my clients can preview what they are getting.

Feel free to login and check things out. This site has lots of hacks, modificaitons and even some custom modules (kinda). A lot of this stuff is behind the scenes. It has been designed for use within Homeowner Associations (for those of you who know what those are).

http://www.dpsystemsonline.com/cms

Feel free to leave feedback here. It's always good to have additional sets of eyes checking your site for those things that can be easily overlooked by the one who coded it.

And not to brag, but I've created a script that allows me to get one of these sites installed, configured and running in under an hour.

In the xoops_version.php file for news, find these two lines of code:



and change it to look like this:



In the code, above, the 1, 4 and 5 refer to groups, so just put whatever groups you want here and only those groups will even see the link.

I believe my solution above is the fix. I was just hoping someone else could confirm my findings and verify it. Always good to have more than one set of eyes looking at the code.

Then you can include it in your next build.

I think I've come across a bug with the permissions and anonymous users.

You have 3 categories and each of those categories can only be viewed by certain groups:

Category 1 -> Registered Users
Category 2 -> Registered Users
Category 3 -> Anonymous Users

Logout of the system and go to the documents section. All three categories are visible even though only category 3 should be visible.

I looked in the functions.php file and came to the conclusion that the $usersid field being passed into the checkMyDownloadsPermission($groupid, $usersid) function is null. This is because no specific users permission were set for that category, only group permissions were set. This makes sense.

Then, you set the $uid null because the current user is anonymous. This also makes sense.

The problem comes further down, around line 120 in functions.php. There is the following block of code:



Since both $userid and $uid are null, this block of code will return true, which indicates that the anonymous user DOES have permission to access the category. Since these two fields will always be null, the anonymous user gets to see all categories. In addition, the $usersid will ALWAYS be null or empty in this case because you can't assign an anonymous user to a category. You can only assign the anonymous group to a category.

I was able to resolve the problem (I need to do some further testing though) by modifying the code of block above to look like this:



What this hack does it simply return false if we have a null user (anonymous) ensuring that the category is not shown.

I was hoping someone else can verify my findings. Please post here.

Thank you.

Since I didn't want an entire "user menu" or "admin menu" cluttering my already crowded screen, here's what implemented.

Each of my themes have a few menu items across the top of the page. I added the following code to each of my theme.html files so make certain links appear based on who is logged in.

This code will show a link to the Admin Panel if the person who is logged in is indeed an Administrator.



This code takes the name of the user currently logged in and creates a link to that users account information, so they can view or edit their profile.



Good luck.

I created a very large SQL script that inserts a bunch of calendar events directly into the database. Here is an example of one of those INSERT statements:

INSERT INTO xoops_pical_event (uid, groupid, summary, sequence, description, transp, admission, class, allday, start, end, event_tz, server_tz, poster_tz)
VALUES (1, 00000, 'Tax Day', 0, 'Tax Day', 1, 1, 'PUBLIC', 1, UNIX_TIMESTAMP('2004-4-15 00:00:00'), UNIX_TIMESTAMP('2004-4-15 23:59:59'), -7, -7, -7);

There are 132 of these statements that insert events throughout the year, in just about every month. All events are "All Day" events. What I notice that for the month of April, the event shows up on the correct day and also the day before. So, if you take the insert statement above for example, the event "Tax Day" will show up on April 15 and April 14. This happens for all events in April and it doesn't matter what year either. When I put the same event for April 15, 2007, the same thing happens.

Also, if I go into the calendar and add the event manually, the same thing occurs, so it appears that it has nothing to do with the SQL statements.

Again, this only happens for the month of April.


Bug number 2:

After inserting all 132 events, I decide to edit one of them. I open up the event and choose the option to "Show as Bar". After I save it, every event that month has a bar, not just the one I checked.

I'll try to do some investigating myself, but there's a lot of code....