Quote:

That is the plan, but, the needs of the XOOPS community ultimately dictate that. If the situation arises that we need a 2.5.8, we will have one. But for now, it is full steam ahead on 2.6.0.

Angelo, can you describe the history of that 2.5.6 system?

We had an issue reported some time ago that when upgrading to 2.5.6, two new columns on the comments table were not added. We never could reproduce that. There was a suspicion that it was language specific.

Any details you could share would be helpful -- things like was it an install or an update from a specific version, what language would have been involved. Any information might help find and fix this issue.

Thanks!

(Earlier bug report on Source Forge)

Something along these lines is planned. This isn't a final product, lots of things are still in motion. Changing the names is not a huge effort. Making sure we maintain a clear upgrade path is. By changing the names now, it makes it much harder on me to keep track of the database differences, so the name changes will happen, but later on.

The actual naming will be different from what you propose.

Everything that creates tables is a module. Some are a subset we call extensions, but they share the exact same naming space as modules. One particular module, system, creates and maintains all of the core tables. But they are all modules, and they all have a module name.

The convention only needs to be modulename_tablename. Otherwise, we waste potentially valuable space for a redundant, and easily violated convention. For 2.6.0, we are only targeting MySQL, but in the near future, we will be adding full support for additional databases, and not all of those have the same generous sizes for entity names.

We will have nice paint on the walls, but I need to finish the drywall first.

That is good news!

Just thinking out loud, but since many frameworks use these exact same tools, I am surprised that wamp (and xamp, easyphp, etc.) don't cover this as part of their base installs. They should. Considering the number of web services that require ssl, shipping with that disabled is a curious choice. Perhaps instead of rehashing this over and over, we should spend some time persuading the *amp stack providers that composer included (or at least friendly) packages would be beneficial for everyone?

I went through a fresh install of WampServer 2.4 (32 bit on a Win 7 box.) After enabling the openssl extension in php.ini, Composer installed without a hitch.

If I understand your issue correctly, composer can't find the php executable.

If you bring up a command line and enter 'path' as the command, you should see a list of directories, separated with a ';', where windows will look for commands. There should be a section that looks something like this:

c:\wamp\bin\php\php5.4.16\;

Make sure that points to the directory that contains php.exe.

Also in that directory (for wamp systems) should be php.ini and phpForApache.ini, make sure that the openssl lines in both are uncommented. My experience suggests that the GUI only sets the 'ForApache' version, so I just use a text editor on both.

If you installed composer using the johnstevenson/composer-setup as suggested by Mamba, it should have captured the path to php.exe as it was installed. If that was wrong, or you changed your system after that, it could be pointing to the wrong place. Go to control panel - programs and right click on composer and choose change. Follow the prompts to reinstall it, and make sure that the path to php.exe points to the right place, for example, c:\wamp\bin\php\php5.4.16\php.exe

Quote:

OK, I suppose I should know this

There were a lot of language and locale changes made by the time of 2.6.0 alpha 2, but it was still a work in progress. There are still a lot of things needing attention to qualify as a complete and workable solution. This is a very high priority area for me. However, there are several changes to the core that are ongoing that will make the resulting i18n solution as strong and powerful as it should be. So, once those changes are in complete, you'll see some progress in that area. Until then, it is kind of a mess. Sorry.

I've got a soft spot for DJ's and Musicians.

Just added your soundcloud tags to 2.5.7.

As to why straight HTML gets filtered out, it is possible to cause all sorts of mischief with that. It has to be limited to use safely, otherwise a site can be hacked fairly easily. It should be possible to apply HTMLPurifier to make accepting HTML safe, but currently, XOOPS relies on BB Code to keep things under control.

As far as I can see, if the field name is valid and if the named field is presented in $_POST, it will be processed and added to the database.

It would be better if the program determined the list of inputs it should expect at the current stage, pulled and cleaned those from $_POST up front, and then worked only from that copy, not directly from the $_POST data. Currently, it merges previous step entries into $_POST and works from that.

This is an annoyance, but the input is still processed just as it would be if the field was part of the entry form.

The 'attack' in this case is not sophisticated. If is just a simple form in an HTML file that points to the real registration form as the action:



Spammers are generally paid workers, and they use toolkits that use forms like these to automate as much data entry as possible. The payload is usually the links included. The dummy value in each field is just to make sure nothing required is omitted.

This is a bug, but by itself it has no security implications; input is handled just as it would be if the field was actually legitimately presented.

This one is significant.

PHP Fatal error: Class 'XoopsMySQLDatabaseProxy' not found in .../xoops_lib/modules/protector/class/ProtectorMysqlDatabase.class.php on line 12

Looks like there is some additional work there to cope with a different connector.

Rod,

I took a deeper look at this, specifically the 2.5 driver, but the results should be relevant anyway.

Using $this->conn instead of the $GLOBAL variable works fine, just as expected. The use of the global connection variable should probably be eliminated.

There are issues with getFieldName() and getFieldType() as both never leave the first column no matter what is specified in the offset. These also have a lot of fluff from the converter program.

getFiledName is easy to fix:


getFieldType is more complicated, but the statement that is in there now is so complex, it would be difficult to maintain. However there is a much bigger issue for future plans. The actual returns in the mysql connector are not clearly defined, and the mysqli functions in PHP returns numeric rather than string data. PDO, as far as I can tell doesn't support that kind of metadata except in an "experimental" method. There does not seem to be any standardization, making the data very driver dependent.

This method doesn't seem to be actively used in the XOOPS world. I have not been able to find a real world test case, just the test I wrote for testing this connector. We should take a serious look at what value it adds to have this method, and consider eliminating it in 2.6 as it seems to be pointless overhead.

I've got a cleaned up version of your 2.5.6 connector. It removes all the $GLOBAL references, and substitutes a big switch to provide names for all of the documented types. (Not exactly elegant, but it doesn't take an hour to figure out what it does.) I would like to get it to you for review; drop me a private email or suggest some other route.

It would be nice to get some support for prepared statements into 2.6 and PDO would be SO COOL! It would also be great if we could get a non-deprecated connector into 2.5.7.

Thanks for all your work!
-Richard