Caching has been fully enabled. Here's a snapshot of top



the 25% usage just hoses the whole system. Still can't find anything in the access logs for it. This is reaching a critical point to where our host is willing to shut us off and terminate our account.

In light of recent events, the traffic on our website kaizoku-fansubs.com has increased almost 100-fold. I do not know if the problem lies with Xoops, but this is a good place to start. Here's what is happening:

Site enabled, traffic starts flowing at about 40-50 hits per second, and everything seems okay. Mysqld pops up from time to time when running top showing a large query go by. Everything continues to be cool.

Something happens.

1 maybe 2 httpd processes jump to consuming every last cpu resource, leaving it impossible for apache to create new threads to handle web requests. PHP is running as mod_php and the host's solution has been to shut us off and leave us off until we can figure out the problem. Here's what we have done so far:

1- disabled our high traffic pages by placing a temporary redirect to a static html page (to prevent httpd binding if it was one of those pages)

2- ran myisamchk on all our tables in order to repair any possible corrupting

3- disabled statistics module (hey, at that many hits, anything is possible)

4- disabled custom XOOPS pages including bittorrent tracker, scrape page, and file parsing scripts. (see step 1)

We are currently in a state where we are running XOOPS with the following:
XoopsCore, newbb, FAQ, WF-Section, XoopsLinks, XoopsDownloads
mods: edituser.php (prevents sigs > 500 characters and image restrictions on size and dimensions)

Our host will turn us on once again this morning, but if things fail again, I am curious where people (core / module / php people) would begin in attempting to disect things. I am (hopefully) going to turn off modules 1 by 1 until we get to the XOOPS core. However, if anyone else has had similar problems, that'd help too.

Cheers!
~Jakob

After racking my brain on this a half dozen different ways...

1) clone the system module "groups" and name it "delgroups"

2) make the following edits:
modules/system//admin/delgroups/xoops_version.php


modules/system/admin/findusers/main.php


No, this is far from perfect, and the language settings aren't working yet. It's entire purpose is to make it possible to use the "find users for this group" feature to remove a user via the search tool. You will come to appreciate even this hacky solution when your user base is more than 3000 users. Sifting through the member id-sorted list to remove a user from the "registered users" group is a pain.

Sysmod Devs: using the select box in findusers.php with a name of fct to call a module's "default action" was a cruel cruel trick, and I couldn't find a better way. Any and all feedback is encouraged, because I am sure there are a half dozen other ways to accomplish this... :)

And lastly, an elegant CSS solution:




Hopefully these will help everyone when
they have users who don't know how to use
the URL tag to clean up their really long
links.


(manual breaks because of above post)

Cheers!

Some additional notes:
it will break the url XOOPS tag (not sure why yet)

it will auto-format all urls

If anyone else is better with RegEx it would be a huge help so that it wouldn't ignore the url tag.

Very quick and dirty fix for people who do things like

http://oh_my_god_this_is_a_long_url_that_will_screw_up_all_your_pretty_layouts.com/youuknow/you/hate/this/to?and=annoying

So, here is the quick fix:

file: /class/module.textsanitizer.php
version: 2.0.5.x
method: replace function &makeClickable(&$text)

Ahem, sorry for the really delayed reply, some stuff in life came up (as always seems the case).

The major benefit to this is integration with existing technology. I am a huge proponent of xoops-designed modules, and often take NewBB over their counterparts. I am almost greatly opposed to hacking core files just to integrate XOOPS with other technologies. Some web applications provide, however, an XML-RPC interface that could be called from XOOPS to submit or retrieve information. The API for it rarely changes, meaning that the same interface usually works from revisionn to revision. I use movable type as an example only because I am somewhat familiar with the posting API. The major bonus of the "module driver" idea would be that XOOPS could for example, post a blog to Movable Type through MT's api interface, and retrieve records using the same module driver.

Given my current position (and new job) it turns out that sometimes the biggest drawbacks to using XOOPS in a business environment is the inability to get it to work with existing technology xyz without having to try and migrate everything. Plus, by writing a module that interfaces with the API, there isn't any core code rewriting going on.

(The springboard for this of course is to research XOOPS own RPC interface if it has one, and see how to for example, make posts by email, have a simple application manage your news postings, update modules, etc)

This was more a wonderment and musing more than anything else. Several high-profile applications, especially in blogging have developed RPC interfaces for submitting and retrieving content. Immediately sprining to mind is Movable Type which has a very comprehensive API. Last night, I started poking at the idea of a Module "driver" as opposed to a Movable Type "module". The idea behind it (in simplified ASCII art) is:

Xoops => MT Driver Module => Movable Type RPC => Movable Type

The process could also be developed for the retrieval of information (via a feed). As a result, the only maintenance that needs to be done is making sure that the driver module is current with both the external program's API as well as the XOOPS module format. Variables such as Movable Type table names can be set in the XOOPS Module Config files.

Has anyone else toyed with this idea and had any experience with this sort of idea? It could make development for 3rd party applications a lot easier.

~Jakob

fixed. same file location, just regrab it. forgot to tack a '"' on the end of the select statement I was using (when adding the register users into group X feature).

Let me know if anything else crops up.

Ah, hmmm, updated versions (as requested) are now available.I forgot I had to do that myself after porting. Anyway, these 2 scripts will do what needs to be done. I didn't have a copy of IPB 2 to test on, so you might need to toy with one of these two.

IPB 1.1.x to XOOPS 2.5.2
http://www.felocity.org/files/xoops_2.0.5.x/ipb1.1.x-users-to-xoops2.5.2.zip

IPB 1.3 to XOOPS 2.5.2
http://www.felocity.org/files/xoops_2.0.5.x/ipb1.3-users-to-xoops2.5.2.zip

Let me know if you have any issues with them! Good luck!
(now that these are finished I will probably also drop them into the downloads section)