PatrickRQ

Who said there is a perfect solution? 😛 I know some communities base/categorize their users within groups.

Not sure on what basis you determined that. I just joined someone's topic and expressed my opinion. I know some communities base/categorize their users within groups. Likely per country/IP, global on off is useless if you allow entire world.

Not my business here, however my personal opinion is: rules are not the same for entire world, therefore admin should be able to decide how to treat selected world areas. Some regions of the world should not be have right to be forgotten upon request. That works mostly for countries with high chance of fraud - some people call it "3rd world countries". When you sell services to such countries, some data should remain longer to protect you against eventual fraud. E.g. I specialized and designed my services to work for such countries, to avoid most of stupid EU regulations, VAT etc. I am telling you from my experience that if you have not worked with such people you will have no basic idea of how different world may look like. Group permission, as additional factor may be helpful depending of construction of specific community. Do not find my post as disrespectful to any nation or region of the world. I just state facts.

I know world is going to treat all equally but I still prefer "grouping people". I guess it was against political correctness? 😂

Too many configs is not good as well, however there is few types of configs IPS @Matt should always consider when designing a system. One of them is per group permission to display or use something. In past, at times of IPB 3x they were adding more of such, starting from IPB4 they somehow stopped doing that.

IPS should finally learn after all the years, that every time they add new feature they should ask themselves a question: "is per group permission required?" personally I miss it in many areas.

I talked about treated updates on crucial areas with more care, e.g. I had same problem.. now when I update such areas I extend tests period and do not care about monthly schedule. My customers like it as I get nearly 0 negative feedback.

HI IPS, I personally do not like this type topics when my Customers post it, and to be honest I have a feeling just I want to click DELETE button, however every time I see such I try to understand them. I noticed that for last few updates you started creating many new issues while fixing other. If you will search forums you will notice that recent updates generated many problems where some were/are related to important areas.. e.g. payments (PayPal), login session.. and many many smaller ones. If you are unsure of quality of specific update, maybe reconsider not pushing update just because you are at the end of your monthly schedule? maybe split updates into 2 smaller ones, to twice a month? as if you will create new issues, your customers must wait a month for next update (since you stopped pushing hotfix releases for a while already). I honestly can understand you often do your best, check things million times, you are happy all is working where at the end some updates are total fail - I know it from autopsy, but if things start to happen for 1-2-3.. updates.. that means some procedure requires correction. Discuss it internally. Thanks.

Version 4.7.11 has too many issues from what I observed in forums. About V3, my bad, I meant V1 vs V2. I will try to compare the two versions and update the endpoint manually, without patching to 4.7.11.

P.S. weren't you switched to V3 api? In PayPal logs I see POST /v2/checkout/orders

The initially mentioned error started to appear very often, people report they are unable to pay and must try using different PayPal account And nothing special/relevant in PayPal API call/error logs. If you want to review yourself you can join me via e.g. TeamViewer and check what you need yourself. Just let me know.

Hi IPS, I use following code in Pages templates {{$records = $recordClass::getItemsWithPermission( array(array('cms_custom_database_'.$category->database()->id.'.category_id=?', $category->id)), $category->database()->field_sort . ' ' . $category->database()->field_direction);}} it generates following error: SELECT cms_custom_database_5.*, author.*, last_commenter.*, core_tags_cache.tag_cache_text FROM `igzxccn_cms_custom_database_5` AS `cms_custom_database_5` LEFT JOIN `igzxccn_cms_database_categories` AS `cms_database_categories` ON cms_custom_database_5.category_id=cms_database_categories.category_id LEFT JOIN `igzxccn_core_tags_cache` AS `core_tags_cache` ON tag_cache_key=MD5(CONCAT('cms;records5;',cms_custom_database_5.primary_id_field)) LEFT JOIN `igzxccn_core_members` AS `author` ON author.member_id = cms_custom_database_5.member_id LEFT JOIN `igzxccn_core_members` AS `last_commenter` ON last_commenter.member_id = cms_custom_database_5.record_last_comment_by WHERE cms_custom_database_5.category_id=24 and field_80< IS NULL AND ( category_can_view_others=1 OR cms_custom_database_5.member_id IS NULL ) AND cms_custom_database_5.record_approved=1 AND cms_custom_database_5.record_approved!=-2 AND cms_custom_database_5.record_approved!=-3 AND cms_custom_database_5.record_future_date=0 AND cms_custom_database_5.category_id IN(17,22,23,24,25) ORDER BY field_80 desc LIMIT 1 IPS\Db\Exception: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'IS NULL AND ( category_can_view_others=1 OR cms_custom_database_5.member_id IS N' at line 1 (1064) #0 /srv/www/public_html/system/Db/Select.php(388): IPS\_Db->preparedQuery() #1 /srv/www/public_html/system/Db/Select.php(446): IPS\Db\_Select->runQuery() #2 [internal function]: IPS\Db\_Select->rewind() #3 /srv/www/public_html/applications/cms/sources/Theme/Theme.php(610) : eval()'d code(2975): IteratorIterator->rewind() #4 /srv/www/public_html/applications/cms/modules/front/database/record.php(350): IPS\Theme\class_cms_database_FXPages_FAQ_Display->record() #5 /srv/www/public_html/system/Dispatcher/Controller.php(118): IPS\cms\modules\front\database\_record->manage() #6 /srv/www/public_html/system/Content/Controller.php(50): IPS\Dispatcher\_Controller->execute() #7 /srv/www/public_html/applications/cms/sources/Databases/Dispatcher.php(343): IPS\Content\_Controller->execute() #8 /srv/www/public_html/system/Theme/Theme.php(4628) : eval()'d code(9): IPS\cms\Databases\_Dispatcher->run() #9 /srv/www/public_html/applications/cms/sources/Pages/Page.php(1260): IPS\Theme\content_pages_172() #10 /srv/www/public_html/applications/cms/sources/Pages/Page.php(2286): IPS\cms\Pages\_Page->getHtmlContent() #11 /srv/www/public_html/applications/cms/modules/front/pages/page.php(116): IPS\cms\Pages\_Page->output() #12 /srv/www/public_html/applications/cms/modules/front/pages/page.php(43): IPS\cms\modules\front\pages\_page->view() #13 /srv/www/public_html/system/Dispatcher/Controller.php(118): IPS\cms\modules\front\pages\_page->manage() #14 /srv/www/public_html/applications/cms/modules/front/pages/page.php(33): IPS\Dispatcher\_Controller->execute() #15 /srv/www/public_html/system/Dispatcher/Dispatcher.php(153): IPS\cms\modules\front\pages\_page->execute() #16 /srv/www/public_html/index.php(13): IPS\_Dispatcher->run() #17 {main} As you can see there is unexpected < in the middle of the query

Hi IPS, Since last 2-3 updates where you touched PayPal/MaxMind code, many customers is unable to pay using their usual PayPal accounts. In logs I find plenty of such: IPS\nexus\Gateway\PayPal\Exception::400 {"name":"INSTRUMENT_DECLINED","message":"The instrument presented was either declined by the processor or bank, or it can't be used for this payment.","information_link":"https://developer.paypal.com/docs/api/orders/v1/#error-INSTRUMENT_DECLINED","debug_id":"82948bc189e09"} Your payment was refused by the payment processor. Please try a different payment method, or contact us for further assistance. Backtrace #0 /srv/www/public_html/applications/nexus/interface/gateways/paypal.php(164): IPS\nexus\Gateway\_PayPal->api() #1 {main} And customers see that Also, logs in the ACP show issue happened to Guest where I am sure, tested it with our client, issue happened to logged it member How come so many PayPal accounts started being refused? Also, in past you printed better information to end-user instead what we see above. You printed actual reason for being unable to pay instead general one that raises questions to us as admins. Hoping for some quick resolution.

Yeah, both does not work. Upload status bar of individual file and overall upload progress bar at the top. The second one works sometimes but showing invalid progress.

yyy..??? The status bar worked pretty well like several updates ago. There was some other report regarding the same. If I upload 100 or 200 MB item I get the same problem.

I just told you. There were 2 payments from same second, both in my PayPal. One was processed, completed (the one assigned to the order on Commerce side) and other one was Pending, requiring my action, to claim or refund the payment. This is how it was handled by PayPal. Both were authorized, but PayPal itself detected something is wrong so I had to either confirm or refuse the second payment. Still no sign of it on IPS end except doubled log entry I assumed is related to the issue.

User is from China, using proxy, said had network issues during processing the payment, so it possibly could be processed twice, however - processed on same order. There should be some protection against such situations anyway. There is no trace of doubled payment in IPB except the logs I provided. Order had assigned first transaction ID and the other transaction was visible only in PayPal. PayPal itself detected something could be wrong and marked the transaction pending, so I had to confirm it (collect) or cancel (refund).

I have test copy, under different sub-domain/database. The member/customer that processed the payment does not exist in the copy, as the copy was taken half year ago and I just use it to test updates. For years I use IPB I never had double payment issue, so I somehow connected it potentially with recent PayPal API updates on your end. FYI, cron task URL is properly adjusted for needs of the test copy, if that's what were you seeking for.

Hi IPS, I believe some issues may be related to some general errors, I found several exceptions logged in the system log, so reporting them here The log entry was triggered by a guest (Guests) May 14 The URL of page the error occurred on was https://www.mydomain/forums/ Exception: DateTimeZone::__construct(): Unknown or bad timezone (Europe/Kyiv) (0) #0 /srv/www/public_html/applications/calendar/widgets/upcomingEvents.php(122): DateTimeZone->__construct() #1 /srv/www/public_html/system/Widget/Widget.php(833): IPS\calendar\widgets\_upcomingEvents->render() #2 /srv/www/public_html/system/Widget/Widget.php(888): IPS\_Widget->_render() #3 /srv/www/public_html/datastore/template_2_94a9d7649fb9cdbfc784d3516e61a717_global.php(18622): IPS\_Widget->__toString() #4 /srv/www/public_html/system/Theme/SandboxedTemplate.php(61): IPS\Theme\Cache\class_core_front_global->widgetContainer() #5 /srv/www/public_html/datastore/template_2_94a9d7649fb9cdbfc784d3516e61a717_global.php(15822): IPS\Theme\_SandboxedTemplate->__call() #6 /srv/www/public_html/system/Theme/SandboxedTemplate.php(61): IPS\Theme\Cache\class_core_front_global->sidebar() #7 /srv/www/public_html/datastore/template_2_94a9d7649fb9cdbfc784d3516e61a717_global.php(7128): IPS\Theme\_SandboxedTemplate->__call() #8 /srv/www/public_html/system/Theme/SandboxedTemplate.php(61): IPS\Theme\Cache\class_core_front_global->globalTemplate() #9 /srv/www/public_html/system/Dispatcher/Dispatcher.php(173): IPS\Theme\_SandboxedTemplate->__call() #10 /srv/www/public_html/system/Dispatcher/Standard.php(113): IPS\_Dispatcher->finish() #11 /srv/www/public_html/system/Dispatcher/Front.php(558): IPS\Dispatcher\_Standard->finish() #12 /srv/www/public_html/system/Dispatcher/Dispatcher.php(155): IPS\Dispatcher\_Front->finish() #13 /srv/www/public_html/index.php(13): IPS\_Dispatcher->run() #14 {main}

Hi IPS, I somehow connect it with recent changes/updates to PayPal API, as for years we never experienced such issue, however I may be wrong. Using 4.7.10, customer reported us that payment was processed twice, indeed. When checked PayPal we had two payments, each under different transaction ID, one processed and one pending. I attach logs for each of logged transactions/issues: The URL of page the error occurred on was https://mydomain.com/checkout/29605/?_step=checkout_pay RuntimeException::0 #0 /srv/www/public_html/applications/nexus/sources/Gateway/PayPal/PayPal.php(328): IPS\nexus\Gateway\_PayPal->_paypalAuth() #1 /srv/www/public_html/applications/nexus/modules/front/checkout/checkout.php(1560): IPS\nexus\Gateway\_PayPal->auth() #2 /srv/www/public_html/init.php(932) : eval()'d code(50): IPS\nexus\modules\front\checkout\_checkout->_pay() #3 /srv/www/public_html/applications/nexus/modules/front/checkout/checkout.php(170): IPS\Helpers\_Wizard->__toString() #4 /srv/www/public_html/system/Dispatcher/Controller.php(118): IPS\nexus\modules\front\checkout\_checkout->manage() #5 /srv/www/public_html/applications/nexus/modules/front/checkout/checkout.php(57): IPS\Dispatcher\_Controller->execute() #6 /srv/www/public_html/system/Dispatcher/Dispatcher.php(153): IPS\nexus\modules\front\checkout\_checkout->execute() #7 /srv/www/public_html/index.php(13): IPS\_Dispatcher->run() #8 {main} The URL of page the error occurred on was https://mydomain.com/checkout/29605/?_step=checkout_pay RuntimeException::0 #0 /srv/wwwpublic_html/applications/nexus/sources/Gateway/PayPal/PayPal.php(328): IPS\nexus\Gateway\_PayPal->_paypalAuth() #1 /srv/wwwpublic_html/applications/nexus/modules/front/checkout/checkout.php(1560): IPS\nexus\Gateway\_PayPal->auth() #2 /srv/wwwpublic_html/init.php(932) : eval()'d code(50): IPS\nexus\modules\front\checkout\_checkout->_pay() #3 /srv/wwwpublic_html/applications/nexus/modules/front/checkout/checkout.php(170): IPS\Helpers\_Wizard->__toString() #4 /srv/wwwpublic_html/system/Dispatcher/Controller.php(118): IPS\nexus\modules\front\checkout\_checkout->manage() #5 /srv/wwwpublic_html/applications/nexus/modules/front/checkout/checkout.php(57): IPS\Dispatcher\_Controller->execute() #6 /srv/wwwpublic_html/system/Dispatcher/Dispatcher.php(153): IPS\nexus\modules\front\checkout\_checkout->execute() #7 /srv/wwwpublic_html/index.php(13): IPS\_Dispatcher->run() #8 {main}

This is how I print it: {{if $formValue != 0}}<div class='ipsMessage ipsMessage_info ipsSpacer_top' data-ipsTooltip title='The version package has been altered'> The package has been re-uploaded at least once, last time on {$value|raw}. Details in <strong>Additional Information</strong> area.</div>{{endif}} As you can see the space is added between date and .

Hi IPS, Would like to report inconsistency of widgets box behavior with general pattern when going mobile. When you add a widget to main column of the forums and go mobile the widget is still boxes, while other forum areas go full width. The behavior of other, non-widgets areas is great on mobile because it gets wider, without losing space unnecessarily. Can you improve widgets to behave the same? It applies to all widgets.

Oh great. Is that mean I do not need to provide access anymore? Thanks!

It really matters? I named the database Faq

This is custom Pages database, by default Pages app has no databases. I just created new pages database, and in Options selected OrderID field as the one used to order records.