I had the comment that I left on Jaxel's XenPorta add-on reported and removed for being "unfair". I have since been allowed to re-comment on his add-on and received this lovely response calling me an "asinine ****":
http://xenforo.com/community/resources/8wayrun-com-xenporta-portal.90/
I think this guy needs to spend less time reading the thesaurus and more time fixing bugs.
Apparently you can fix this by making changes to his add-ons (replacing the word public with protected). I made the foolish assumption that there was actually some reason for him being such a terrible developer and having changed the word from protected to public in the first place (hence changing it back would break his add-on) but he assures me that isn't the case. I haven't tested it and I'm just an "asinine ****", so what would I know.
Let me know if you try it out.
No apology necessary. Can I encourage you to point this out to the developer of XenPorta and keep pestering as he really needs to fix this... or I might have to resort to building 'WainPorta'.
or I might have to resort to building 'WainPorta'.
XenForo_Exception: The requested user could not be found. - library/XenForo/DataWriter.php:1321
Generated By: Unknown Account, 47 minutes ago
#0 /home/sociall1/public_html/forums/library/XenForo/DataWriter.php(1363): XenForo_DataWriter->_haveErrorsPreventSave()
#1 /home/sociall1/public_html/forums/library/bdBank/XenForo/DataWriter/User.php(25): XenForo_DataWriter->save()
#2 /home/sociall1/public_html/forums/library/Waindigo/SelfDelete/DataWriter/UserDelete.php(49): bdBank_XenForo_DataWriter_User->save()
#3 /home/sociall1/public_html/forums/library/XenForo/DataWriter.php(1422): Waindigo_SelfDelete_DataWriter_UserDelete->_preSave()
#4 /home/sociall1/public_html/forums/library/XenForo/DataWriter.php(1361): XenForo_DataWriter->preSave()
#5 /home/sociall1/public_html/forums/library/Waindigo/SelfDelete/Model/UserDelete.php(86): XenForo_DataWriter->save()
#6 /home/sociall1/public_html/forums/library/Waindigo/SelfDelete/CronEntry/SelfDelete.php(26): Waindigo_SelfDelete_Model_UserDelete->updateUserDeleteRecord(Array, '', 'deleted')
#7 [internal function]: Waindigo_SelfDelete_CronEntry_SelfDelete::selfDelete(Array)
#8 /home/sociall1/public_html/forums/library/XenForo/Model/Cron.php(356): call_user_func(Array, Array)
#9 /home/sociall1/public_html/forums/library/XenForo/Cron.php(29): XenForo_Model_Cron->runEntry(Array)
#10 /home/sociall1/public_html/forums/library/XenForo/Cron.php(64): XenForo_Cron->run()
#11 /home/sociall1/public_html/forums/cron.php(12): XenForo_Cron::runAndOutput()
#12 {main}
array(3) {
["url"] => string(59) "http://www.sociallyuncensored.eu/forums/cron.php?1352180762"
["_GET"] => array(1) {
[1352180762] => string(0) ""
}
["_POST"] => array(0) {
}
}
Bug fixes:
- Fixed 'The requested user could not be found' error in Server Error Log when user is deleted by cron task.
Fatal error: Access level to Waindigo_SelfDelete_ControllerPublic_Abstract::_preDispatch() must be public (as in class XfAddOns_Blogs_ControllerPublic_Abstract) in library/Waindigo/SelfDelete/ControllerPublic/Abstract.php on line 30
This is the same problem as before. The developer of Better Blogs appears to have taken the approach that I was unwilling to take in order to avoid incompatibility with Jaxel's add-ons. This is exactly what I warned would happen if Jaxel didn't fix his add-on quickly as it has now resulted in other add-ons having to break from convention.PHP:Fatal error: Access level to Waindigo_SelfDelete_ControllerPublic_Abstract::_preDispatch() must be public (as in class XfAddOns_Blogs_ControllerPublic_Abstract) in library/Waindigo/SelfDelete/ControllerPublic/Abstract.php on line 30
Seems like there is a conflict with this add-on.
Better Blogs
http://xenforo.com/community/resources/better-blogs.1055/
To be clear, my BS patch was a failure upon further review. While it didn't give me the error upon visiting those add-ons.... It prevented people from posting new content by changing public to protected.This is the same problem as before. The developer of Better Blogs appears to have taken the approach that I was unwilling to take in order to avoid incompatibility with Jaxel's add-ons. This is exactly what I warned would happen if Jaxel didn't fix his add-on quickly as it has now resulted in other add-ons having to break from convention.
Perhaps you would be so kind as to inform Rigel about your Anti-BS patch and suggest that he fixes his add-on and point his users in the same direction if they have incompatibility issues with Jaxel's add-ons?
To clarify the convention that needs keeping to, in XenForo all methods that start with an underscore (_preDispatch in this case) must be protected and NOT public. The error message is misleading because it states that it "must be public" but this is only because someone (namely Jaxel) has broken the convention.
From http://framework.zend.com/manual/1.12/en/coding-standard.naming-conventions.htmlFor methods on objects that are declared with the "private" or "protected" modifier, the first character of the method name must be an underscore. This is the only acceptable application of an underscore in a method name. Methods declared "public" should never contain an underscore.
What I know and everyone else should know is when your add-on is installed.... It conflicts with over 12 other add-ons, made by different developers, and some of them well skilled and respected. The only common denominator in it is this add-on.From http://framework.zend.com/manual/1.12/en/coding-standard.naming-conventions.html
This is not something that I have just made up.
I'm not even talking about Jaxel or his add-ons, which I'm not using. There are dozens of other add-ons which have an issue with this add-on (yours), coded by other developers. And NO, they do not depend on Jaxel's code or his add-ons.Only some of them well skilled and respected? Not all? Lol.
As I understand it Jaxel has already fixed the issue with his add-on but didn't feel that it was worth releasing because he thought it was such a small bug. I hope you are giving him as much hassle as you are giving me.
What add-ons?What I know and everyone else should know is when your add-on is installed.... It conflicts with over 12 other add-ons
public function _preDispatch($action)
protected function _preDispatch($action)
Important potential security bug fix:
- Although no specific issue has been identified, it is possible that a user may be able to gain access to restricted information produced by other add-ons if those add-ons are not properly secured and that information is usually visible on the front-end of the site by a restricted group of members (see below). The Admin Control Panel has not been compromised in any way. Updating this add-on to the latest version will close this security...
We use essential cookies to make this site work, and optional cookies to enhance your experience.