Thanks so much everyone.

I suspected that I'd have to bring in the list of users and check each one for the appropriate account (or just do a direct query myself), but I was hoping that there was a neat little method somewhere already in the api that I was just overlooking.

Quote:

Well, it's a long story, but maybe someone will find it interesting?? Anyway, this server also hosts lots of SVN Repositories (close to a thousand and growing). We have a neat little web-top going that allows folks to browse through the repositories and check-out, or simply download, whatever they'd like to work on.

We've been adding new features to this. For instance, Illustrators can now use SVN meta-data to mark a directory for automated uploading into our CMS database (not Xoops, something else) whenever they check-in changes via SVN. We also automatically generate thumbnails of graphics and show them while browsing around the web-top interface.

The final thing we were gonna do was add a sort of search. We don't need a complete indexing of all the content in SVN, since most of the 'stuff' that we'd want to search for is already hosted in that other CMS that I mentioned. But it would be nice if you were an Illustrator and could search/find the location of "really-cool-graphic.eps" across all our repositories.

So, I thought that it might be nice to perform an indexing operation after every repository commit action that would gather and store the path, author, revision #, revision date, and log information for each repository item. This information is getting stored directly into xoops tables for a module that I'm also writing. This module is very simple in that it really only implements the search feature of modules. There is no admin interface, main menu presence, or even general-purpose module pages for a user to view. They will, however, be able to search across filenames and log data. The search results will take them to the associated pages in our web-top. And, finally, the stylesheets for all this stuff is set up so that users of our site can't really tell that they're bouncing around amongst various websites on the same server. It'll all looks like they're in Xoops the whole time.

Now, to answer your question. SVN stores what we call the shortnames of folks who commit changes to the repositories. We've hooked Xoops to LDAP for authentication, so these very same shortnames are the Xoops nicknames on their accounts. So, during this search action, I need to go from nickname to userid so that I can pass that back. The Xoops search engine will then convert that into a clickable author link on the search results page. It's a small detail, but one I'd like to go ahead and implement.

Thanks again everyone for your help on this. Greatly appreciated!!!

---

Oh, and now that I'm thinking about it, I'll probably want to do this action during the indexing operation itself by just directly looking up the information with a MySQL query. That way, the work will be done during the batch indexing operation that nobody is waiting for rather than the search results algorithm that someone *is* waiting for.

I'm rusty on module development in Xoops. I have a nickname and I need to look up the user id and return it as part of making my /modulename/include/search.php file. For the life of me, I cannot remember an easy way to look up the user id!


$ret[$i]['uid'] = 0;

Need something better than zero here.

Thanks everyone.

I finally got around to really looking at this problem. Here is the solution (for others that might care):

Version 2.05
Pages Sort Incorrectly

Issue Description
The RSS feeds and the "Posts by Author" pages quit working. Specifically, results were no longer sorting newest to oldest --- but just the opposite. The RSS feed fails because new items never get delivered to the RSS reader. The "Posts by Author" page fails simply because it isn't very usable to have to scroll to the very end to see the most recent posts (which one, presumably, most often wants to see).

Issue Solution
After much poking around in the source code we found that the GROUP BY / ORDER BY implementation changed from one version of MySQL to the next. This caused the issue when a recent Xampp upgrade was performed.

The needed fix was to eliminate the GROUP BY clause from the SQL query completely. This fix may have unintended side effects. For now, however, everything seems to be fine.

~line 654 in wp-includes/classes.php:


~line 506 in wp-includes/template-functions-links.php:

Nobody? Darn. I was really hoping someone had some idea of what might be going on here.

BTW: Love the 'stars' being changed to Xoops' orb symbols!

Xoops, version 2.0.18.1
Wordpress, version 2.0.5

I have the multi-author wordpress for XOOPS module installed. I'd ask this question at XoopsForge, but that site seems to be having issues at the moment (index.php = blank page, submit to forum = blank page, etc.).

Anyway, I've got a site that, as of just a couple of days ago, sorts blogs in ascending by date order. Normally, you'd click on an author's name and see their latest blog followed by older ones all the way back to the beginning. Now, all of the sudden, the reverse it true. The oldest entries show up at the top.

I have no idea what could have done this. I have recently upgraded my Xampp stack.

From:
# Apache HTTPD 2.2.4 + Openssl 0.9.8e
# MySQL 5.0.45
# PHP 5.2.3

To:
# Apache HTTPD 2.2.9 + Openssl 0.9.8h
# MySQL 5.0.51b
# PHP 5.2.6

I can't imagine that making a difference though.

I don't see any options anywhere to control sort order on these pages. I know I'm not crazy, too, since I have another site who's sort order is still correct (newest to oldest). Has anyone seen this before? Does anyone have any ideas on where I would begin looking to alter this??

Thanks so much in advance!

+1 btesec.

I vote TinyMCE.

I've encountered what I think may be a bug. I have a custom module here. I updated one of my templates. Installed the upgrad onto the server. Updated the module in the admin section. Then, when viewing my module, the template is still showing the older version.

So, I then delete all the cache files in the templates_c folder and try again. No luck. So I get poking around in the templates section of the admin panel. When updating my module, the updated template gets updated in the "XOOPS Default Template Set". But the problem here is that I have another template set currently selected. Shouldn't XOOPS realize that I have another template set selected and update the templates there too when updating a module?

This may or may not be a bug. I may simply not understand the 'why' of how it works. Perhaps after updating a module, I am supposed to go and delete all the templates in my currently selected Template Set for that module and regenerate them. If so, this isn't something that I've been aware of in the years that I've been using Xoops.

Any and all commentary on this subject is much appreciated. Please weigh in on what I might be doing wrong or how you think it should work. Thanks!

For what it's worth, here's my simple hack to the core that gets around my immediate problem:

original code:



new code (NOT THE IDEAL SOLUTION!!):

I have a question about some code in the core. This may have been changed in more recent versions. It might not have either. Here goes...

In the change function, your basically setting up the XOOPS User account with data pulled from somewhere else. In my case, it's from a LDAP. My problem is the email field. Sometimes, an e-mail address isn't present in the LDAP for a given user account. When this happens, the change function tries to load in the e-mail (which is an empty string) and gets an error. This is because the XoopsUser object is defines e-mail as a required field.

So there seems to be a slight disconnect here. Now, I could update the core very easily and literally "create" the e-mail address in real time since our company's e-mail addresses are name@company.com ... and we have the name they logged in with. So, I can solve this problem for myself. The general XOOPS community, however, might have a bit of a problem. There should be some error handling in this function to account for required XoopsUser fields that are not present in the $datas variable. It errors out right now. That's OK, I suppose. But the result is that some subset of your users simply won't be able to log on if there is something wrong with their LDAP account. Compounding this is the fact that they won't know it's their LDAP account that's the problem and may never need to bother with even trying to tell you (the webmaster) about the problem.

It would probably be better if the "Xoops-Auth server fields mapping" parameter in the "Authentication Options" screen would allow you to not only define field mappings, but also designate default values for those fields if they are missing (or maybe if they are missing *and* required).

Bonus points if you can specify certain variables so that you can create default values on the fly. For instance instead of this value:

Quote:

maybe you could expand it into something like this:

Quote:

The above would mean that the name variable in XoopsUser gets the cn field in the LDAP database. The email variable in XoopsUser gets the mail field in the LDAP database. But if that value is missing, it gets the name of the user plus "@company.com" as the value instead. The {name} means use the name variable that's already defined and the rest is just a literal string.

Does anyone else think this is a good idea. My vesion is a little old now, maybe this has already been worked on. I wish I had a little more time or I'd implement it myself and provide the code. Wait long enough and I just might do that! :)

Xoopsforge is making reference to MediaWiki for XOOPS 1.67, so I'm going to assume that's the latest until I hear back from anyone hearing something else.