Hi there,

Pageworks is really just a mini CMS for PHP code instead of HTML content. So just like if you wrote a custom PHP file, you will have to figure out how to get the data you need from the News module.

You will need to add whatever the right code is to communicate with the News module and its datatables, and then whatever that is, you should just be able to plunk it down inside your Pageworks page.

Sorry, but I don't have experience gathering data from the news module. I wonder though if including a recent news block on Pageworks module pages would be one simple solution?

Good luck,

--Julian

I should add that the "taxonomy" stuff that was discussed recently in relation to XOOPS was not really so lofty as the entire "semantic web" which is what my previous post here was about.

I think what most people in XOOPS-land are interested in right now, regarding taxonomies, is some kind of common taxonomy system for content, like what Drupal has. This has been discussed in XOOPS before. Whatever the challenges in implementation, it seems pretty clear that any modern "CMS" should have some kind of common categorization system.

The real question, I think, is what is the benefit of having a common categorization system in XOOPS? In Drupal, it gives you cross-referencing of content, which is built into the Drupal core. In XOOPS, there's no core features like that, period. So just building the categorization system isn't enough. You can't just have a way of tagging everything as one kind of content or another kind of content. You need those tags to then cause something else to happen, such as having pages in the core that list content across modules, according to the categorizations.

Meanwhile, there are other things XOOPS does pretty well, like multi-language, and templating, that are probably higher on the list. I think it's important to be careful to push XOOPS strengths and not spend too much time trying to play catch-up. We'll never out-Drupal Drupal, so let's not try to have the world's best taxonomy system. If taxonomy is *the* feature someone needs, they won't use XOOPS, period. So let's focus on what makes XOOPS really good, and make that better. Taxonomy will be important to have in XOOPS at some point, but let's keep everything in perspective.

--Julian

Hello,

I recently answered a question you had about this in the Formulize forums on dev.xoops.org, sorry for the delay.

Reading the whole description of the problem here...this can be done with Formulize, in fact we have built quite a neat little signout and return system for a client. But it takes some rather advanced knowledge and tricks to get it right. Not a good first project with Formulize. If you want to give it a shot, post again on the dev.xoops.org area for Formulize and I can try to describe what is necessary.

I think it would take you about 20 to 30 hours to set this up in Formulize. It took us about 10, but obviously we're going to do it faster than others. Depending on the skills available, you might just want to write your own module.

--Julian

Thank you to those who encouraged me to step forward here! I would not do it without your support.

I have over 7 years experience working in PHP, and got my ZCE designation last year.

I am a founder of Freeform Solutions, a not-for-profit organization that helps other not-for-profits use technology to meet their mission goals. We have built several XOOPS sites over the last few years.

I also develop and maintain the Formulize project which is an advanced XOOPS module that does everything and makes coffee. Almost.

I have presented at a few conferences and elsewhere about XOOPS and Formulize.

I'll make no bones about it...our interest in XOOPS is focused around the parts of XOOPS that are necessary for Formulize to function. The key things there, are user/group management, permission management, and the whole forms class, which has stagnated for way too long.

The key thing for the health of the XOOPS project, is to unite the 2.0.x and 2.2 branches. The core development team should stop forking XOOPS itself and instead release something that lets people move forward from the code they have.

I look forward to helping give direction and life to the next phase of the XOOPS project.

--Julian

Just for the record...iMenu 2.3 is compatible with XOOPS 2.0.16. I'm not sure what the problem was, and you've got a menu working now, so that's great. If you do want to debug the issue in iMenu further, please post to the Formulize area on dev.xoops.org, accessible through:

http://www.freeformsolutions.ca/formulize

Good luck,

--Julian

@ preachur

Sorry to hear the problem persists. I can't think what would be causing that other than the register.php, edituser.php, userinfo.php and the related system template file not being replaced during install...the reg codes versions of those files simply ignore the default form and use the one you've specified in the Formulize preferences instead.

I am happy to take a look at your site in more detail, including through FTP to check the files, if you are comfortable with that. Let me know.

@ carpeweb

You can make life fairly simple for users by creating a page with links to the register.php file, with the right code added on as a URL parameter. So if you have three classes of users, and each needs to register with their own code, so they see the right questions in the profile form and/or so they are slotted into the right groups, then if you give them links to click on with the code in the URL, they don't have to remember the code, and they can just read the link text and click the one that makes sense for them. ie:



I hope that helps,

--Julian

Quote:

You're welcome!

Quote:

Have you replaced the XOOPS core files with the copies from Registration Codes? The most likely explanation is that you have not done that step.

Quote:

If you have everything setup and working correctly (ie: your custom form is appearing when you go to register a new account), then you as an administrator can go to the user profile form you made, in Formulize. You can view the entries in there just like in any other form.

Formulize/Registration Codes 2.3, just released, adds one additional feature to the approval process: users must confirm their e-mail address, before administrators are notified of the account. This ensures that people actually are typing in their own e-mail address (or at least one they have access to!).

Good luck,

--Julian

Quote:

Thanks for the plug!

It is true, Formulize can be used to do all of that. You would have to spend some time customizing the forms and configuration of course. Questions, etc, welcome on the Formulize discussion area on dev.xoops.org (accessible through that link above).

I should point out that the integration with WF-Downloads is somewhat separate from regular Formulize. You can customize the upload forms in WF-Downloads, if you have Formulize installed (and you have WFD 3.2, or 3.1 with the integration patch). However, you cannot add upload fields to any Formulize form. That is a feature that seems continually on the drawing board, but has never been needed quite enough to make it to reality.

--Julian

Hello, sorry you ran into trouble. The basic cause of the error message you found is that you have not given permission to the Registered Users and Anonymous Users group, to access the User Profile form.

If you go into Formulize, and into the Modify Form Access Permissions area, then you should give those two groups view_form, add_own_entry and update_own_entry permission on the User Profile form.

That should resolve that issue.

In general, read the readme file for Registration Codes very carefully, there are several options, and several steps to go through, but once they're done, it works well.

Your second issue about bypassing the "enter your code" screen....

You should change all references in your site that point to "register.php", to point to "register.php?code=nocode" instead. That's the simplest solution. That will take you straight to the form, as it would appear to a user who had entered no code.

I hope this helps, let us know if you run into any other issues.

--Julian

Quote:

Thank you for publishing this report. There was a typo in the xoops_version.php file which was preventing that table from being removed correctly. This is fixed now and will be included in the next release.

--Julian