FEU Change Settings not working and logoff redirect

[nathan4610]

Ok, New to the forums so ill try and give you the info that was addressed in the "how to Ask"

I just freshly installed cmsms on my linux host using

CMSMS Version 2.1.3
FrontEndUsers 1.31.3
CGExtensions 1.53.6
CGSimpleSmarty 2.1
CMSMailer 6.2.14

PHP 5.6
MySQL 5.5

This is addressing Front End Users module.
I can login, forgotten password form works, forgotten login form works, however when I login and then click on change settings it does not load the form for that. Also in the settings I have page redirect set for after login which does work, but upon logoff the redirect does not.

I have searched the forums and could not find a fix for the settings change not showing up, or anything about the page redirect failing.
I am new to this cms, so im going to have a few more questions if i can get this resolved. TIA

[klemkas]

I have the same problem, clicking on "change settings" goes to the same screen with "change settings" link, in another words, nothing happens, no form to change user properties.

Where to start looking for a problem?

[gdur]

To all facing similar problems:
I've communicated extensively with the author over the last two week detailing all my findings. The response was: Works For Me. (???).
Obviously not a satisfactory nor helpful answer.

This is what I've communicated on July, 12th 2016 regarding my observations but haven't got an answer as yet:

Have a page (pageID 33) called Login which includes some text + {FrontEndUsers} tag.

Redirect is defined in "Builtin Authentication" to pageID 36. This is a protected page (service section). And indeed after a successful login you are redirected to this page.

Having {FrontEndUsers} on this page as well enables to either Change Settings or Sign out. Selecting "Change Settings" results in staying on the same page while the content is being wiped out while the redirect setting points to pageID 38 which is a page made for this purpose (Change settings page). Looking into the address bar it states "/index.php?mact=FrontEndUsers,cntnt01,default,0&cntnt01form=changesettings&cntnt01returnid=38" while the setting of PageID/Alias to jump to after change settings: is clearly 33. At this point I'm confused whether returnid means the page to go to after submitting but if that's the case that would be odd. Anyway have a look at the screenshot attached where you also can see that this is still the Home» Service Section page (36) where I initiated Change Settings. Singing out is resulting in an attempt to still display the same page (Service Section) but obviously no longer allowed (see attachment 3) while thePageID/Alias to jump to after logout *: is set to 1 (home page).

Side note: I'm intending to use {FrontEndUsers} on every protected page so users can sign out where ever they are. The place holder "Welcome $emailaddress " seems somewhat overdone. Easy to remove but that un-necessary maintenance whenever upgrading. My suggestion is to cramp this in as a user defined variable on the Builtin Authentication admin page.

Logging in while making an error (i.e. wrong captcha) result in wiping the original content of this page. (see attachment 4(before) and 5(after)).

Forgot Your Password? stays on the same page (Login) while "PageID/Alias for Forgot Password form:" points to pageID 39 (Specific Lost Password page). Again Content disappeared. returnid in address bar says 33 (login page, being still the current page). As a side observation one cannot cancel without inputting the e-mail address(?). This shouldn't be too hard to code that differently.

Forgot Your Login Details? result in staying on the same page (Login) but being empty(?).

Side note: I'm intending to use {FrontEndUsers} on every protected page so users can sign out where ever they are. The place holder "Welcome $emailaddress " seems somewhat overdone. Easy to remove but that leads to un-necessary maintenance whenever upgrading. My suggestion is to cramp this in as a user defined variable on the Builtin Authentication admin page.

Whether these observations are due to a possible conflict with the standard/default templates as offered after an initial fresh install I couldn't tell but others would experience the same as my testing seems to be pretty straight forward.

A question what comes to mind is whether variables are declared local rather than global as these seem to be empty after moving to another page upon login. As a last test for today I removed the redirect after login but it keeps on jumping to the page originally set (36).

[gdur]

Hi johnboyuk,

Thanks for confirming my findings. Hopefully this leads to a fix. Thus-far my post has been ignored other than "Works for me". I really hope that a second bug report will help to get the appropriate attention.
Let's keep fingers crossed...

[Jo Morg]

Any developer needs precise steps to reproduce an issue. Even then, there is a chance that the issue may not be easily reproducible given the fact that the number of factors involved in a particular installation is too high for the developer to be able to have them all covered or to test them all.
Developers need to be able to reproduce the issue in orderto try to fix it. The expression "works for me" means that the developer, having tried to reproduce the issue, was unable to do so: it did work as expected given the information provided.

In the number of factors that may not be reproducible by the developer are included installations in which the number of upgrades have been possibly high, and some may have gone wrong, corrupted database tables (more frequent than you would expect and not easy to diagnose), user error (more frequently when the user fails to take a look at the readme and changelog files when provided), server environment incorrectly setup, etc...

That's also why we have a "How To Submit a Question So You'll Actually Get Help" sort of guide, which is not a complete guide to submitting bug reports already goes a long way in that direction.

[gdur]

Hi Jo,
Appreciate your input however much more detailed information has been passed on to Calguy offline.
The steps I took were fairly straight forward: A new install, no complains about anything wrong with the environment. OS is CentOS 6.x which is mostly used by providers I believe. Only added the modules required because of dependencies resulting in the experience I've stated above.
Invested a lot of time to figure out where it goes wrong. Reported the install failure of 2.02 within a couple of hours and which was than fixed the very same day...
Just noticed that today version 2.061 has been published and the "Change log" only states "Numerous small bug fixes and optimizations."(?). I've not have had the time to try it out but jumping from 2.03 to 2.061 makes me wonder...
I hope the least that my input has been taken into account but some more active feedback or response would have been nice though.
I will report later whether v2.061 does what can be expected from.

[gdur]

Following up my previous reply here is the result:
Behavior as in my first reply remains persistent. Sadly no improvement in 2.061 compared to 2.03. Still the same inconsistency.
Clearing cache and cookies or not influence behavior but never result in something useful.

[klemkas]

I'm having very dubious feelings towards cmsms. I remember it being an awesome cms, now after a few years, i got back, and find unsolvable problems. I found this bug report from year 2012, and still in 2016 i'm having the same problem, without a solution (http://dev.cmsmadesimple.org/bug/view/7978).
Latest version, default installation, only FEU extensions with dependencies, no more modifications. I'll try to test it on my computer without restrictions of free hosting to rule out the third party problems.

[klemkas]

Scratch that. The solution was posted one thread below.
http://forum.cmsmadesimple.org/viewtopi ... =7&t=75222

[gdur]

Gradually things seem to improve. Page re-directs seem to work since FEU version 2.07.
The "Change My Settings" link still doesn't work as should but it does go to the page as defined in the Admin Section. Sadly the page is still blank. I modified this page adding {FrontEndUsers action='changesettings'} and while calling this page directly it does format as expected. At this point I found a bug because submitting changes settings leads to a blank page stating "here3" due to a bug in "action.do_userchangesettings.php" on line number 358. die('here3'); needs to be removed.
Until the "Change My Settings" link has been resolved you could define a specific page for that purpose and include {FrontEndUsers action='changesettings'}.
You also may consider to create a temporarily fix by changing line number 5 in the "FEU logout form" template from "<p><a href="{$url_changesettings}" title="{$mod->Lang('info_changesettings')}">{$mod->Lang('prompt_changesettings')}</a></p>" to "<p><a href="index.php?page=change-settings" title="{$mod->Lang('info_changesettings')}">{$mod->Lang('prompt_changesettings')}</a></p>" where 'page=change-settings' in this example represents the alias of the specific Change Settings page.
Obviously you need to monitor whether the "Change My Settings" issue has been resolved in any future release.