Hi, @tstarling ! Thanks for the comment! With replacing rollback() with cancelAtomic() as suggested - all works as expected. But if to proceed with testing with sleep() usage I got next error:
$status = $form->show();
Hi, @tstarling ! Thanks for the comment! With replacing rollback() with cancelAtomic() as suggested - all works as expected. But if to proceed with testing with sleep() usage I got next error:
Thanks, @tstarling for the comment!
Hi, @Tgr, @tstarling ! Could you please tell, if we can just go with 'ORDER BY nli_issue_id DESC' statement instead of 'MAX' statement, so no aggregation is used any longer, ( $options['LIMIT'] = 1 is added in the Databese::selectField method in any case ). Maybe we could also add an INDEX on 'nli_issue_id', 'nli_newsletter_id' fields,. And that would be great to somehow test the execution speed. Thanks!
Hi, @Tgr ! Could you please describe the easiest way to reproduce the issue locally (if possible) - I need it to properly describe fields props: (label, help). Thanks!
Seem 'label' (something else as well) should be returned by getFieldInfo() method, I will check if it will not break something. -> so the annotation (from the task https://phabricator.wikimedia.org/T247886) to abstract method getFieldInfo() is to be changed as well. Will that be ok if the changes from https://phabricator.wikimedia.org/T247886 will be made here, together with the needed changes ? Thanks!
Hi, @Ijm8710 ! Yeh, the thing is that some further investigation is to be made, as @MSantos mentioned, when we had a chat with him regarding this issue. So there is chance that the change will not be needed. If not, there is a patch for dark(and other) themes cases, which is ready and will be reviewed and merged if needed (after the investigation). Thanks!
Thanks, @schoenbaechler for the reply!
Thanks, @MSantos !
I've taken 3 of <sup> as an example to show that a touch target of a <sup>, that is surrounded with other <sup>s, will be increased from the top and bottom only, So the behaviour, described in the example will be applied to any number of <sup> elements -> ( <sup> >=3).
Here they are:
("Michael_Lewis_(wide_receiver)" taken as an example)
Thanks, @MSantos ! Patch created.
@MSantos , could you please tell if this change sufficient\looks good:
Due to @Pchelolo comment:
Hi, @MSantos , Thanks for the info! Yes, it is clear. The patch updated - now tests pass. Thanks!
Hi, @MSantos , @Jgiannelos ! I'm trying to push changes https://gerrit.wikimedia.org/r/c/mediawiki/services/wikifeeds/+/667990 to wikifeeds, but test fails (https://integration.wikimedia.org/ci/job/service-pipeline-test/7941/console) due to empty content for /page/news for "es" subdomain. -> "es: results list should have expected properties". Could you please tell what can be a reason ? Thanks!
Hi, @Dbrant , @LGoto ! Could you please tell if the mentioned change in the current task ("Media help should not be displayed") and in this one: https://phabricator.wikimedia.org/T269385 ("References in Spanish Wikipedia shouldn't have columns") need to be made on the mobile app level or do we need (can we ?) to change the templates ? Thanks!
There is a setting here: https://github.com/wikimedia/wikifeeds/blob/master/lib/random.js#L71 -> 12 items are requested. Maybe we could increase this value ?
Or there is a possibility the testing should be performed in some specific way ?
The same for iOs - tested 300+ random articles - no duplication. Also looked through the php code (which is responsible for the content (random articles) ) - the "randomness" is very high.
@MSantos, could you please comment on the next proposal :
What was done:
From my conversation with PPchelko regarding the task:
For now it will be enough to handle empty response (as mentioned in the desc, there is a separate ticket to improve the iOS) as it happens..., and as we've got deferred updates of the data, mentioned here - the task can not be resolved by itself except the change: "remove the reference to English." (will not eliminate the root problem, but this change is good to have from my point of view).
So there is an architectural issues wich is good to take a look in the future.
The Idea is just to: make DAOAccessControl::get() to return a string - like "$msg->text()" and not an $msg obj. as now.
In T265361#6540657, @Ammarpad wrote:Have wrote patch for this in T246567