The following warnings occurred:
Warning [2] Undefined variable $unreadreports - Line: 26 - File: global.php(961) : eval()'d code PHP 8.2.25 (Linux)
File Line Function
/global.php(961) : eval()'d code 26 errorHandler->error
/global.php 961 eval
/printthread.php 16 require_once
Warning [2] Undefined property: MyLanguage::$archive_pages - Line: 2 - File: printthread.php(287) : eval()'d code PHP 8.2.25 (Linux)
File Line Function
/printthread.php(287) : eval()'d code 2 errorHandler->error
/printthread.php 287 eval
/printthread.php 117 printthread_multipage



UserSpice
verify.php bug and possible solution. - Printable Version

+- UserSpice (https://userspice.com/forums)
+-- Forum: Support Center (https://userspice.com/forums/forumdisplay.php?fid=23)
+--- Forum: UserSpice 4.3 and Below (https://userspice.com/forums/forumdisplay.php?fid=26)
+--- Thread: verify.php bug and possible solution. (/showthread.php?tid=237)

Pages: 1 2

verify.php bug and possible solution. - brian - 09-09-2016

I think I have run up to the same issue with my testing where paths aren't right or something like that. On a previously activated account, I set the email_verified flag to 0 and tried logging in, resulting in a redirect loop, and then eventually a 404 when I tried going back to the root of the US install.

At least the issues are somewhat known now.

***Edit***

I have resolved my issue with the redirect loop. But I'm not sure if your issue is the same as mine was. If you could summarize any issue you still have with verify.php I can double check that use case.

verify.php bug and possible solution. - plb - 09-11-2016

It would be nice to know where this is going, long-term, so that current development apart from US (but using US helpers and classes) doesn't have to be re-worked.

Are you aiming for a relative path in Redirect::to() which will then be prepended by various paths (perhaps in Config)?

Or are you aiming for an absolute path in Redirect::to() which would go directly to the desired page?

verify.php bug and possible solution. - mudmin - 09-11-2016

UserSpice 4 is going to be supported indefinitely even if things change in future development, so there shouldn't be an issue. Anything new added to the database is being designed to not conflict with old stuff.

As always, if you're going to modify core files (which will be less and less necessary moving forward) you're definitely encouraged to use the usersc folder. If you need to modify functions, as often as possible it would be great to include your own custom scripts and functions in a different file and then include them somewhere like in your own init...something we're definitely not ever going to change in US4.

I'm going to make a roadmap forum where we can start talking about direction on this stuff.

verify.php bug and possible solution. - plb - 09-11-2016

I was wondering about the Redirect::to() function specifically - as I develop should I use

Code:
Redirect::to('script.php');

or

Code:
Redirect::to('my/app/script.php');

or

Code:
Redirect::to($us_root_url.'my/app/script.php');

It depends how you are going to move forward with the development of Classes/Redirect.php

verify.php bug and possible solution. - mudmin - 09-11-2016

Basically all 3 of those will work. Originally UserSpice was all in one folder, so it wasn't really an issue. In general I side towards going with the most complete path unless you have a reason you want your links to be relative. I'd lean towards number 3 personally.