iacas

I had a member sign up recently and AutoWelcome didn't seem to fire. It's enabled, and everything should be working just fine.

PHP 8, IPS 4.7.6… and so far as I know, everything else is okay.

8 minutes ago, Martin A. said:

You can also run this query to have it run hourly (Don't do this with a 1000 limit tho!)

Ha ha. That would annoy the other members too much (even if I set it to 50 or 75 every hour) because… they'd have to dismiss a bunch of new markers all the time.

I like 1000 or so once a day. There will be days I run it manually once, too.

Thank you.

2 hours ago, Martin A. said:

Yeah, changing the limit on file is how to do it. Do mind that it's now sending 1000 requests to Geoapify at once, this may result in a timeout and it's not actually processing 1000 members. Not that it really matters, as it will redo those it couldn't on the next run.

Yeah. I did a few of the 100-run ones (like 10 or 12), then I changed it to 1000 and did it once.

Still good. And still 43,000+ remaining. 😄 Doing it by the hundreds… they'd still be processing in 2024.

Is there a way to bump it up from processing only 100 at a time? To like… 2000 at a time? I've been running this for awhile now and still have 45000+ to process.

I changed the $limit to 1000 on line 54 of the task. That may do it.

The first post checkbox was for merging the first post with a subsequent post, not for merging topics, though, right?

Not sure what you're asking exactly. (Just a user here, of course.)

54 minutes ago, Martin A. said:

How many members are you going to import? You can manually run this task as many times as you'd like, just be aware of the daily API quota that you should exceed. Search for "tasks" in the ACP search to get to the task manager.

Ah, I had searched for "member" and "commu" and "map" and didn't see it. For others, the task is called "locationSync". I'll run it a few times now.

Processing 100 member map markers per day is annoying and bad for my site: visitors who don't visit every day are going to miss out on posts and content that's new that occurred just before that day's processing of markers.

Is there any way to mark these as read for everyone? Or to not have them show up as "new" in a default stream of "unread" content, @Martin A.?

Or at least… let me process ALL of them instead of 100 at a time, so they're "out of the way"?

2 hours ago, Martin A. said:

As the user, as an admin, or in the ACP? I tried this on my install. Changed the location in the profile field that is selected in the profile sync setting, the change was immediate.

As an admin on the public profile page. The location was Youngsville, Louisiana. He had typed in "Youngsville, LA" and it located it somewhere near northwestern NY, so I changed it to "Louisiana" and nothing changed, so it may have simply been a matter of… a map failure to locate the correct location, even with the state name in it.

On 12/7/2022 at 12:37 PM, Martin A. said:

You changed it from the marker view, in his profile or on the map while signed in as the user?

In his profile. Previously this resulted in an immediate change to the marker.

8 hours ago, Martin A. said:

Members are imported in a daily task, max 100 per day. You can manually run this from the task manager if you want it to run more often. 

I see that happening now. 100 or so yesterday, 100 or so today. Thanks for the heads up.

I changed the location of a member today… but his marker never updated its location. This was nearly immediate before. Hours later, it still hasn't been updated.

34 minutes ago, Martin A. said:

The new version is submitted and is currently pending approval.

I'd mention it again; All of you will need to sign up for a new API at Geoapify. Your current API key from Mapquest will not work.

Done. Thank you.

Did you try the fix noted above?

1 minute ago, Adriano Faria said:

All fine in IPS 4.7.4, PHP 8.1 or 8.1 and default (unmodified) theme:

Works here too on the same setup.

Well, okay. I made a backup of the modified file(s), because the patch did modify those files, so I was able to quickly revert to put the fix back in.

For others, or myself if I goof in the near future…

            if ( \count( $data ) )

became

            if ( is_countable( $data ) AND \count( $data ) )

Thank you. All set now.

6 hours ago, Daniel F said:

Thanks,

I can confirm that we fixed this bug in our next maintenance release. ( I have applied the patch to your system to confirm that nothing else is broken) so you should be fine now.
Please keep in mind that because of these changes, your support tool will show now that some original IPS files were customized! 

Thanks.

Should I apply this patch, and then restore the Widget.php files that you modified? Or does this patch include that fix (it doesn't seem to)?

On 11/10/2022 at 8:55 AM, Marc Stridgen said:

It's the ftp details we need also in order to resolve the issue. Please let us know once that is ready

Should be set.

2 hours ago, Marc Stridgen said:

We would need to look further into this for you, however the access details on file appear to be incorrect or missing. Could you please update these details by visiting your client area, selecting the relevant purchase, then clicking "Review/Update Access Information" under the "Stored Access Information" section. 

We look forward to further assisting you.

The access credentials are all correct except the SFTP stuff. I'm waiting on something for that. It'll be updated to what's on file, so it may begin working again (the SFTP stuff) before I'm able to get back here to say so.

But everything else - admin panel access - is correct.

Anything, @Marc Stridgen or @Mark H?

thesandtrap.com

I'd already done those steps in trying to figure it out before, but I did them again just now and it still generates the error. It happens on a default theme (even though it's not tied to a theme, and my theme is a lightly modified child theme), and I disabled all third-party plugins and applications.

The details in the support thing should be accurate. I manually ran all the other "cleanup" tasks, but the main "cleanup" one still generates the error above.

@Adriano Faria, I'm using the advice above to see if I might be able to fix this, too:

Oh, sorry, thought those would merge. I appreciate the help with the iAwards bug/issue.

When you split this into its own topic, I lose the follow, so I didn't even see that you posted this reply until I went to look for my own post.

8 hours ago, Adriano Faria said:

 

Quick and easy fix. FTP required.

Download applications / awards / tasks / autoAwardRules.php and find:

	public function execute()
	{
		foreach( \IPS\awards\Rule::roots() as $rule )

Change to:

    public function execute()
    {
        $rules = array();
        foreach( \IPS\awards\Rule::roots() as $rule )

Save and upload.

Thank you! That seems to have solved it.

Still getting the same error with autoAwardRules on IPS 4.7.4.

I don't have any auto-awarded rules. I created one, to see if that would make the error go away, and it still gave the error.

My cleanup task has seemingly NEVER completed (not lately, anyway):

It gives this error when run manually:

As text, that's:

TypeError: count(): Argument #1 ($value) must be of type Countable|array, null given (0)
#0 /path/to/site/system/Widget/Widget.php(1009): IPS\cms\_Widget::getUniqueIds()
#1 /path/to/site/applications/core/tasks/cleanup.php(263): IPS\_Widget::emptyTrash()
#2 /path/to/site/system/Task/Task.php(274): IPS\core\tasks\_cleanup->execute()
#3 /path/to/site/applications/core/modules/admin/settings/advanced.php(754): IPS\_Task->run()
#4 /path/to/site/system/Dispatcher/Controller.php(107): IPS\core\modules\admin\settings\_advanced->runTask()
#5 /path/to/site/applications/core/modules/admin/settings/advanced.php(38): IPS\Dispatcher\_Controller->execute()
#6 /path/to/site/system/Dispatcher/Dispatcher.php(153): IPS\core\modules\admin\settings\_advanced->execute()
#7 /path/to/site/adminstuff/index.php(13): IPS\_Dispatcher->run()
#8 {main}

I've just now started looking into it. IPS 4.7.3, PHP 8.1. No patches available.