I just tested the feature on your site, — and I notice the notification sitemail landed directly in the "Arcived" folder! It did show an increase in unread mail count though.

To fix, open up /core/ajax/report.php, and under line #210 ($mail['mail_type'] = "report"), add the following:

$mail['mail_tags'] = "inbox";

This will make the reports go where they belong. Bug confirmed, fixed for the upcoming build.

When you test this, also note that new mail status is updated on 60 second intervals (as defined in $core['sys']['member_refresh_intv']), and as such the mail number in the header will take a moment to change.

"I just went into admin and approved the member and an email was sent to the test user (I suspect to inform them that they are approved) but the content and subject are blank."

There's a missing variable declaration in function users_default() in admin_area_users.php. On line #34, add in the missing $lang variable;

    global $core, $lang, $skin;

Then, do the same change at line #132, at the start of function activate_all_pending().

There is an identical bug in the same context in function send_new_password() in /core/ajax/members.php (#960), change to read follows:

    global $core, $lang, $skin;

This fixes a blank message on password recovery. Bugs confirmed and fixed.

"E-mails that get sent out all seem to have a double listing of Subject"

Yes I notice this, there are two subject headers. I haven't seen any e-mail client display two though, so this hasn't been caught in the net — guess it's usually filtered out.

Open /core/class_mailer.php, find this (#177), and delete the red portion:

        $headers = array (
            'From' => $sender,
            'Subject' => $subject);

This should remove it. Bug confirmed & fixed.

I will poke around this with Safari to see what's up — it looks like blank serialized data there, need to see if I can trigger it to appear somehow. If it appears before the form is saved, I'm pretty sure it's a harmless quirk in either case, and shouldn't affect your end result.

Yes indeed, if you select just one option, it displays the expected value, but when you select multiple options, it displays the values. Tagged as confirmed bug.

To fix, go to /modules/members/members_class.php, and find (#625):

else $data['fdata_content'] = str_replace("|", ", ", $data['fdata_content']);

Replace with the following:

                else
                {
                    $multi_opt = explode("|", $data['fdata_content']);
                    $opt_buffer = array();
                    foreach ($multi_opt as $val)
                        $opt_buffer[] = $options[$val];
                   
                    $data['fdata_content'] = implode(", ", $opt_buffer);
                }

This will sort it out for you. Fix entered into next build. Todo: Do the same for Form Builder and test.

I bumped into the same issue as I was working on the Wiccle.com updates.There is a fatal error when a thread is submitted into forums in WWB build 1.0.1.

This issue is caused because there are subfunctions inside a function that's generally only called once; in this case, it's called on two instances as the page is processed, and the functions become declared again, leading to a fatal error.

To fix this, open up class_elements.php. In there, you will find three functions that cause this, starting at line #45 and function make_namedate_ident(), and ending at #95 after make_verbose_ident(). Just add this conditional statement around them:

if (!function_exists('make_namedate_ident'))
{
   ...(three functions in here)...
}

This will prevent them from being declared twice, and the error is solved. This bug has been fixed for the next release.

Speaking of Forums, there is also a configuration variable that went missing as I was doing cleanup for the 1.0.1 release. Add this line into your variables.php file to prevent a  Notification level error from appearing on servers with error reporting cranked up for PHP:

$core['module']['posts_per_thread_page'] = 20;

Yes, this happens if you click Quote on the mail that you see below the editor in the preview panel. Tagged as bug, fixed for next build.

To fix this, open /core/ajax/message.php at line #286:

        $mail = Utility::array_stripslashes($mail);

Add after:

        $mail['mail_id'] = !empty($mail['mail_id']) ? $mail['mail_id'] : mt_rand();

This will give the mail shown in the AJAX area a proper identifier, fixing the parsing issue (resulting from defective Quote/Reply buttons missing an ID).

To get rid of the [[MODMENU NAME]] code that now appears, simply remove the spacers (marked "x|" as the name) in Admin CP > Menu Builder > Module Menu. If you want to keep the spaces but want to get rid of the unparsed tag, open up class_templates.php #1974, and replace the following:

            $tmp['module_menu_name'] = "";
            $tmp['module_menu_link'] = "";

With this:

            $tmp['modmenu_name'] = "";
            $tmp['modmenu_link'] = "";

The above is a bug that has been fixed for the next release.

--

I notice that the [[CPARENT]] language tag (that should translate into "Blog" — "cparent" as in "capitalized parent") doesn't get parsed properly. Flagged for investigation and fixing.

In general, these are unparsed language tags, and where they still exist, I will need to check the core to see where they are parsed and why the language strings don't get parsed in as expected.

Okay, problem identified and bug confirmed. Switched on debug mode with Articles, and noticed the query run for creating a new article's table of contents affects a broader scope than intended (post_cache fields get overwritten).

The fix is actually embarrassingly simple in WWB. Open up articles_class.php, and find (lines 197-201):

if ($_GET['show'] == "add_post")
{
     $ref_id = 0;
}

And simply delete or comment them away. This will eliminate the problem. This fix (with additional Articles module fixes) will be included in the next update. (This was actually a deprecated piece of code still ghosting around.)

iWiccle requires a bit of additional code editing or file batching, as it doesn't support yet the form processing extension that WWB uses to handle this.

There will be a WWB update coming out in the course of Monday, and an iWiccle maintenance release (1.21.2) to follow in the course of the week. (I will need to compare the two builds, integrate code from WWB to iWiccle, and take it for a test spin. Shouldn't be too complicated however.)

Hi Rezashah, and thanks for reporting! I havent checked the system with Farsi yet, a full multilanguage sweep is on my near future tasklist. (Hopefully addressing all multilanguage problems across scripts.)

The problem with AJAX happens because the Unicode post data gets encoded while it passes through javascript, and then fails. Just haven't had time to crack this one yet, it shouldn't be too complicated to sort out.

Bug report tagged.

Thanks for reporting — this bug was gracefully easy to fix. Bug report confirmed and patch file issued. The problem is a misconfigured query that filed post comments under member wall comments, and therefore didn't include the correct post ID into the database.

The problem is in skin_comment.php on line #67 under $skin['comment_form']. Where it says:

submitAjaxGet('general_ajax', 'member_comment&action=load_form

It should read:

submitAjaxGet('general_ajax', 'post_comment&action=load_form

This bug crept in when I was synchronizing member and post comment forms.

If you don't want to fix it manually, you can download a patch file (ZIP, 1.68KB). If you have a customized template but haven't edited your skin_comment.php file, doing this will not change your template modifications in any way.

This fix has been added to the Patches page listing, and will be included in the next build. This bug does not affect Wiccle Web Builder 1.0.

In Wiccle Web Builder 1.0, thumbnails for certain module feeds (such as Store in eCommerce Portal) are not correctly displayed in small size format.

The Store module uses a larger default thumbnail size (80px) than most other modules (where 60px is the default).T his results in a broken image when content is drawn from one module (Store) into another (Site).

In cross-module use, instead of considering the source module's configuration, the core currently uses the configuration of the parent module for image sizes and the such. This issue is on my list of core fixes to apply as soon as possible. (Currently templates and language files are properly "enveloped" between modules, and config is the last remaining hurdle to cross between full cross-module content mixing.)

Until the core improvement is rolled out, there is a simple fix to the issue. Simply place the following into an empty .htaccess file and upload it to /uploads/store/thumbs folder.

RewriteEngine On
RewriteRule ^s60_(.*)$ s80_$1

You can also download a ready .htaccess file (click here) if you wish, and upload it into place. Note that this will only work on webservers running Apache with mod_rewrite on (which should be the case with most respectable hosting servers).

---

Related info: Configuring Image Sizes in Uploads and Templates

There's a little bug in the member post decrement feature when an administrator deletes a member's post.

Be sure to mention which counter drops out of the loop; I suppose you mean the member's posts counter (yes you do, just fixed it). I have covered increments and decrements to parent and category level counts in delete and move situations with posts and threads, as well as parents in categories and vice versa, at least I think I have! Debugging all that is something I haven't tagged as a super urgent on our list of priorities, especially since the idea is to get in place a general resynch tool into the Admin CP.

It's just one line of code in /core/ajax/tasks.php, and I notice we have a little bug on the radar (#323):

Queries::do_query(Queries::decrement_member_entries($_SESSION['member']['member_id']));

There's a little quirk above as you might guess by looking at it and thinking what might happen, as it will decrement the posts of the person logged in, and doesn't consider you might be an Admin and might be actually deleting someone else's posts. (And you will end up with minus posts in the end, unless you post more than you delete!) Simply change that line to:

Queries::do_query(Queries::decrement_member_entries($data['post_member_id']));

And that should take care of it. All the AJAX-based delete functions happen through this file. I've noticed some of the other counters can also get a bit out of synch in some situations, but haven't had the focus and interest to hunt them down systematically yet. If you spot such situations, please inform.

There is a bug in the iWiccle 1.20 class_iwiccle.php file that causes last_active status to not update. If you have upgraded from 1.20 to 1.21 prior to this message, you will need to grab an additional file that was missing from the upgrade bundle. If you did a fresh 1.21 install, this feature is working fine and you don't need to do anything.

----

The last_active status (and new mail status) should be updating every 60 seconds. You can change that in variables.php / $core['sys']['member_refresh_intv'] = 60; if you want.

The case here is this: it was not working in 1.20, and it is working in 1.21, but I forgot to add the updated class_iwiccle.php into the upgrade bundle. Naturally the last active time was then the same as last registered, as it never got updated again.

Download the forgotten file here: iwiccle_121_class_iwiccle_patch.zip

And just upload it over your existing /core/class_iwiccle.php file. Sorry about that! Need to triple check through the upgrade bundles in the future to make sure nothing goes amiss. I have now updated the upgrade bundle with this, and added a note of the same to the patch page.

There went cold and forgotten my cup of hot instant soup that I meant to sip down after reading your post and nailing this, but what the heck — another bug down!! Cheers, and let's all have a cup of cold soup for my bug allergies and a better iWiccle.

There is a bug in the module description mouseover javascript seen in the site header; it breaks when you use quotes. Here is the solution.

It seems that the use of "quotes" breaks it. If you want to fix this (as I just have for the 1.21.1 build), open up class_templates.php at #1570 and change the following:

        $data['module_mo_description'] = addslashes($data['module_description']);

To:

        $data['module_mo_description'] = addslashes(htmlspecialchars($data['module_description']));

This converts the quote into a HTML entity and will let it pass through. I have tested this in our demo, and you can now see that the News module description now also works with quotes.

Confirmed and fixed bug effecting "posting to global parent" if you have modified your iWiccle 1.21 module configuration to change the default functionality.

On this issue of defunct custom global parents, I can confirm the issue after creating a second account and testing how blogging etc. works. I have compared your 1.20/1.21 config files, and there is a key difference that causes this for two of your modules — along with a minor bug in class_forms.php that makes sure the issue applies across the board!

Gallery Module

1.20: $core['module']['req_owned_parent_for_post'] = FALSE;
1.21: ---

Video Module

1.20: $core['module']['req_owned_parent_for_post'] = FALSE;
1.21: ---

This was removed from the two config files because they run by default in "parent for every member" mode, and to tell you the truth it didn't cross my mind to debug each module in both modes before release. We haven't really officially announced dual mode modules as a feature yet! It's on the map with the Wiccle eStore module that can be used in three modes; 1) single parent ("department") with categories, 2) multiple admin departments with categories, and 3) separate shop with categories for every member (of a membergroup with permissions).

The "make your parent" prompt is triggered in class_forms.php at line #661 (1.21 version below) by the following conditional check:

 if (($core['module']['req_owned_parent_for_post'] === TRUE ||
$core['module']['global_parent']) && empty($_SESSION['cache'][MODULE_IDENT]['my_parent']))
....

Now that I have it open here, there's actually a little booboo in the above that was introduced in 1.21. It should read $core['module']['global_parent'] === FALSE of course (just add  === FALSE), while the little omission you see above instead evaluates the value for TRUE. Make it check for the global_parent config being false as above, and that (along with the two config changes above) should set it straight for you. I have updated this goof into the 1.20 release. The correct line #661 that lets you post in both modes in iWiccle 1.21 now reads:

if (($core['module']['req_owned_parent_for_post'] === TRUE || $core['module']['global_parent'] === FALSE) && empty($_SESSION['cache'][MODULE_IDENT]['my_parent']))

I was obviously in the middle of extending the clause above to check for config two options, and got distracted somewhere or otherwise accidentally deleted it.

To sum the above up, if you want to avoid the "make your parent" prompt, you need to have these two settings in your configuration files:

$core['module']['req_owned_parent_for_post'] = FALSE;
$core['module']['global_parent'] = TRUE;

Having them the opposite will turn the module into "parent for each member" mode, while the above will have them in "shared/global parent" mode. To tell you the truth, now that I look at the usage of these two switches across the system, they seem to be aliases that just work on reverse, and are both used in different contexts (the "global parent" in older code, and the "req_owned_parent" in newer code). Sorry for the confusion, I will standardize this for a future release, dropping the "global_parent" switch from system evaluations, and aliasing it on the fly to keep up legacy setting support.

If you need to compare files in the future, you can for example crack them open in Notepad++ and use the compare tool (ALT+D), which runs a difference of the two files and lets you compare and scroll them side by side. Very handy for situations like this. As below (the 1.21 side of blogs config as an example from my compare):

Resolution for a PHP 5.1.x compatibility issue

Your problem being this (looked up error logs in the logs folder):

[Mon Jan 25 12:02:59 2010] [error] [client 99.3.190.5] PHP Fatal error:  Call to undefined function  memory_get_peak_usage() in /usr/---/htdocs/core/class_errors.php on line 175

memory_get_peak_usage(), I note, was introduced in PHP 5.2, while your server is still on 5.1.x. While our specs still say 5.1.x or higher, it's really something we should change to say 5.2.x because 5.1.6 for example is four years old, and has a bunch of security holes and quirks that have since been patched.

The offending function is in /core/class_errors.php at line #175, and can be modified for example as follows until you upgrade your PHP version:

$core['runtime']['memory_peak_usage'] = "N/A"; // round(memory_get_peak_usage(TRUE) / 1024);

I have done the change, included the register_globals off switch as it's really necessary to have in place, and your site is up and running smooth. Please verify that things are in order, and I will then delete all copies of your FTP access details at my end. (We do not store logins for a number of reasons, you will need to resend them in the future if you need me to access the site again.)