1.3.6 Help with Dynamically Generated Images

[T1K]

Yeah it still throws the error even with an image loading. I just remembered I forgot to implement it saving as an image (I think it's on like page one or two) so I can try getting that up and see if it does anything.

I'm not seeing the error anymore so I think you should be good to go once the image saving functionality is implemented. Example without an error: http://pixellatopia.mysidiahost.com/picuploads/adopt_images/1.png

Vs. one with the error still: http://pixellatopia.mysidiahost.com/picuploads/adopt_images/2.png

Also, you can go ahead and delete phpinfo.php, and this specific line in view/main/myadoptsview.php now:

$document->add(new Comment("<br><br>" . var_export($this->getField('image')) ."<br>"));

 

[emotidogzz]

I'm not seeing the error anymore so I think you should be good to go once the image saving functionality is implemented. Example without an error: http://pixellatopia.mysidiahost.com/picuploads/adopt_images/1.png

Vs. one with the error still: http://pixellatopia.mysidiahost.com/picuploads/adopt_images/2.png

Also, you can go ahead and delete phpinfo.php, and this specific line in view/main/myadoptsview.php now:

$document->add(new Comment("<br><br>" . var_export($this->getField('image')) ."<br>"));

Getting this error:

Fatal error: Uncaught TypeError: Resource\Core\AppController::setField(): Argument #2 ($value) must be of type ?Resource\Native\Objective, string given, called in /home/pixellat/public_html/controller/main/myadoptscontroller.php on line 47 and defined in /home/pixellat/public_html/resource/core/appcontroller.php:183 Stack trace: #0 /home/pixellat/public_html/controller/main/myadoptscontroller.php(47): Resource\Core\AppController->setField('image', '/adoptimage/vie...') #1 [internal function]: Controller\Main\MyadoptsController->manage('1') #2 /home/pixellat/public_html/resource/core/frontcontroller.php(196): ReflectionMethod->invokeArgs(Object(Controller\Main\MyadoptsController), Array) #3 /home/pixellat/public_html/controller/main/indexcontroller.php(13): Resource\Core\FrontController->triggerAction() #4 /home/pixellat/public_html/resource/core/frontcontroller.php(142): Controller\Main\IndexController->triggerAction() #5 /home/pixellat/public_html/index.php(77): Resource\Core\FrontController->handleRequest() #6 /home/pixellat/public_html/index.php(86): IndexController->run() #7 /home/pixellat/public_html/index.php(90): IndexController::main() #8 {main} thrown in /home/pixellat/public_html/resource/core/appcontroller.php on line 183

 

[T1K]

Getting this error:

Fatal error: Uncaught TypeError: Resource\Core\AppController::setField(): Argument #2 ($value) must be of type ?Resource\Native\Objective, string given, called in /home/pixellat/public_html/controller/main/myadoptscontroller.php on line 47 and defined in /home/pixellat/public_html/resource/core/appcontroller.php:183 Stack trace: #0 /home/pixellat/public_html/controller/main/myadoptscontroller.php(47): Resource\Core\AppController->setField('image', '/adoptimage/vie...') #1 [internal function]: Controller\Main\MyadoptsController->manage('1') #2 /home/pixellat/public_html/resource/core/frontcontroller.php(196): ReflectionMethod->invokeArgs(Object(Controller\Main\MyadoptsController), Array) #3 /home/pixellat/public_html/controller/main/indexcontroller.php(13): Resource\Core\FrontController->triggerAction() #4 /home/pixellat/public_html/resource/core/frontcontroller.php(142): Controller\Main\IndexController->triggerAction() #5 /home/pixellat/public_html/index.php(77): Resource\Core\FrontController->handleRequest() #6 /home/pixellat/public_html/index.php(86): IndexController->run() #7 /home/pixellat/public_html/index.php(90): IndexController::main() #8 {main} thrown in /home/pixellat/public_html/resource/core/appcontroller.php on line 183

This is one of the errors that was fixed earlier in the thread. Was it accidentally overwritten / undone?

 

[emotidogzz]

This is one of the errors that was fixed earlier in the thread. Was it accidentally overwritten / undone?

Possibly, I was using this post

 

[T1K]

Possibly, I was using this post

You'll need to reintroduce the change to getImage() in model/domainmodel/ownedadoptable.php to fix the most recent error.

Here's a more up to date version of the function that includes the change we recently made to $home as well. I've gone ahead and gotten rid of that variable, since we can get the value we need directly from the constant now:

public function getImage($fetchMode = "") {
    $lastImgUpdate = $this->getImgLastUpdate();

    if ($this->getLastUpdate() !== $lastImgUpdate) {
        return new Image(SCRIPTPATH . "adoptimage/view/{$this->getAdoptID()}");
    } else {
        return new Image(SCRIPTPATH . "picuploads/adopt_images/{$this->getAdoptID()}.png?{$lastImgUpdate}");
    }
}

How's everything coming with the image generation code?

 

[emotidogzz]

You'll need to reintroduce the change to getImage() in model/domainmodel/ownedadoptable.php to fix the most recent error.

Here's a more up to date version of the function that includes the change we recently made to $home as well. I've gone ahead and gotten rid of that variable, since we can get the value we need directly from the constant now:

public function getImage($fetchMode = "") {
    $lastImgUpdate = $this->getImgLastUpdate();

    if ($this->getLastUpdate() !== $lastImgUpdate) {
        return new Image(SCRIPTPATH . "adoptimage/view/{$this->getAdoptID()}");
    } else {
        return new Image(SCRIPTPATH . "picuploads/adopt_images/{$this->getAdoptID()}.png?{$lastImgUpdate}");
    }
}

How's everything coming with the image generation code?

Sorry, linked the wrong post!! I meant I followed this one!

Now I'm getting this again: Fatal Error: Class Controller\Main\picuploadsController either does not exist, or has its include path misconfigured!

 

[T1K]

Sorry, linked the wrong post!! I meant I followed this one!

Now I'm getting this again: Fatal Error: Class Controller\Main\picuploadsController either does not exist, or has its include path misconfigured!

This error is still being caused by the fact that there is no file located at picuploads/adopt_images/1.png (nor 2.png, 3.png, etc. for any adoptable ID).

Judging from adoptimagecontroller.php, you want for the generated image to be saved to picuploads/adopt_images. If we can get this to work, then your "picuploadsController does not exist" error will be fixed.

When I go to the adoptimage/view URL, I'm seeing the following error:

 Warning: Undefined variable $images in /home/pixellat/public_html/controller/main/adoptimagecontroller.php on line 76

Looking at adoptimagecontroller.php this seems to be because the $images variable is only defined in the first else block around line 29 in the view() function. Each of these blocks in the if/else/elseif sequence will need to declare that variable, or, if you want for every level to use the same markings, you can remove the if/else/elseif portion and just declare $images at the base level in that function.

Let me know if you have any questions about this change - once you've made it, let's try again and see if any new errors pop up, and work from there. I noticed that there is a warning about $markings not being defined as well, so I imagine we still have a bit of work to do.

 

[emotidogzz]

This error is still being caused by the fact that there is no file located at picuploads/adopt_images/1.png (nor 2.png, 3.png, etc. for any adoptable ID).

Judging from adoptimagecontroller.php, you want for the generated image to be saved to picuploads/adopt_images. If we can get this to work, then your "picuploadsController does not exist" error will be fixed.

When I go to the adoptimage/view URL, I'm seeing the following error:

 Warning: Undefined variable $images in /home/pixellat/public_html/controller/main/adoptimagecontroller.php on line 76

Looking at adoptimagecontroller.php this seems to be because the $images variable is only defined in the first else block around line 29 in the view() function. Each of these blocks in the if/else/elseif sequence will need to declare that variable, or, if you want for every level to use the same markings, you can remove the if/else/elseif portion and just declare $images at the base level in that function.

Let me know if you have any questions about this change - once you've made it, let's try again and see if any new errors pop up, and work from there. I noticed that there is a warning about $markings not being defined as well, so I imagine we still have a bit of work to do.

Yeah, I only want the change to affect level 1+. I'll see if I can figure out how to change that lol

 

[T1K]

Yeah, I only want the change to affect level 1+. I'll see if I can figure out how to change that lol

Here, give this a shot. I've annotated the file with some comments to explain what's going on throughout it. Let me know if you encounter any errors with it.

In this version, it will apply the markings in your picuploads/adopt_images folder to all adoptables level 1 and up. I'm not sure if this is what you wanted, or if you wanted for the markings to be different according to their level; if that's what you want then you'll probably need to create directories for the different levels' markings, like picuploads/adopt_images/level_2/ and etc. (and then we would update the images paths accordingly in the code).

To show the dynamically generated image you'll want the image source to be /adoptimage/view/$adoptID. After it's generated you can also link to it by the usual picuploads/adopt_images/$adoptID.png URL.

Also, it just doesn't show anything right now for adoptables at level 0, since I'm not sure what you wanted to do for those.

 

[T1K]

Update: I had a bit of extra time this evening, so I went ahead and drafted a version of the above that allows you to use different markings for each level.

You'll need to create folders for your level markings if you decide to use this version of the file. Some prerequisites to note:

• These folders will be nested under picuploads/adopt_images
• Each folder will be named level_$number, where $number is the number of the level (obviously)
• Each folder will contain 25 images named marking1.png through marking25.png respectively

So for example if you wanted level 1 to have green markings you would create a folder named picuploads/adopt_images/level_1 and upload marking1.png, marking2.png, marking3.png, and so on up until 25.

For any levels that don't have a folder, it will fallback to using the base directory (picuploads/adopt_images) as a default. So make sure that you also have the marking files in there.

 

[emotidogzz]

Update: I had a bit of extra time this evening, so I went ahead and drafted a version of the above that allows you to use different markings for each level.

You'll need to create folders for your level markings if you decide to use this version of the file. Some prerequisites to note:

• These folders will be nested under picuploads/adopt_images
• Each folder will be named level_$number, where $number is the number of the level (obviously)
• Each folder will contain 25 images named marking1.png through marking25.png respectively

So for example if you wanted level 1 to have green markings you would create a folder named picuploads/adopt_images/level_1 and upload marking1.png, marking2.png, marking3.png, and so on up until 25.

For any levels that don't have a folder, it will fallback to using the base directory (picuploads/adopt_images) as a default. So make sure that you also have the marking files in there.

Hmm, still getting: Fatal Error: Class Controller\Main\picuploadsController either does not exist, or has its include path misconfigured!

This code will allow me to change the hexes of the markings through the database still though, right?

 

[T1K]

Hmm, still getting: Fatal Error: Class Controller\Main\picuploadsController either does not exist, or has its include path misconfigured!

This code will allow me to change the hexes of the markings through the database still though, right?

Yep, this will still use the hexes you have in the DB.

As for the picuploadsController error, we can expect to continue seeing that until we get the adopt image controller fully working. I'm seeing now that it's showing the following error on the /adoptimage/view page: "Oops... you aren't supposed to be here." I wasn't able to find that text in a default Mysidia installation - can you let me know which message that text is associated with in your installation, so I can narrow down which part of the codebase is triggering that message?

 

[emotidogzz]

Yep, this will still use the hexes you have in the DB.

As for the picuploadsController error, we can expect to continue seeing that until we get the adopt image controller fully working. I'm seeing now that it's showing the following error on the /adoptimage/view page: "Oops... you aren't supposed to be here." I wasn't able to find that text in a default Mysidia installation - can you let me know which message that text is associated with in your installation, so I can narrow down which part of the codebase is triggering that message?

Awesome.

Found it. I think I may have forgot to edit this file correctly. I'll see if I can get it working.

 

[T1K]

Awesome.

Found it. I think I may have forgot to edit this file correctly. I'll see if I can get it working.

I took some time earlier to finally set up a dev environment and get Mysidia installed, and I was able to get this working for 1.3.6 by making some changes to the view file and the controller. There are still a couple of tweaks that I want to make for improvements, but at the current moment it's creating the image and saving it; however I'm not 100% sure that it's doing what we expect it to with the marking images, since I'm not seeing my test marking change to the color corresponding to my adoptable's hex value.

I'll upload what I have in the morning once I finish those final tweaks to the view file, and then let's see what we can do about the marking images / color generation. ImageMagick is not something that I'm familiar with so this will be a good learning experience.

 

[T1K]

So, here's the solution that I came to.

By default Mysidia will display the view associated with a controller like a page on the site, so it doesn't seem to be possible for us to output a content type other than HTML this way. Or at least I didn't find it if it is possible.

Since this script is meant to show an image ultimately, I decided to go ahead and extract its logic from the controller class and create a separate script in the root directory of the Mysidia installation. I named this script adoptimage.php.

Then from there, I updated .htaccess to route all requests for /adoptimage/view to that script. Firefox won't let me attach this file so here are the contents of it and you can update it manually:

RewriteEngine On
RewriteRule adoptimage/view/([0-9]+)$ adoptimage.php?id=$1 [L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !\.(js|css|html|xml|json|gif|jpg|png|ico)$ [NC]
RewriteRule ^(.*)$ index.php [QSA,L]
RewriteRule ^get/([0-9]+).gif$ /click/siggy/$1 [L]

Finally, to fix an issue I was seeing with the adoptable model, I had to add properties for the newly defined columns in model/domainmodel/adoptable.php. I also updated it to use AllowDynamicProperties since the number of markings may change over time.

At this point the images are generating for me, but I'm not seeing the correct color applied, even though I am seeing that it has the expected hex value when it goes to call evaluateImage().

I don't know if this is an issue with the images I'm using or what, so when you run this, let me know how your image comes out.

 

[emotidogzz]

So, here's the solution that I came to.

By default Mysidia will display the view associated with a controller like a page on the site, so it doesn't seem to be possible for us to output a content type other than HTML this way. Or at least I didn't find it if it is possible.

Since this script is meant to show an image ultimately, I decided to go ahead and extract its logic from the controller class and create a separate script in the root directory of the Mysidia installation. I named this script adoptimage.php.

Then from there, I updated .htaccess to route all requests for /adoptimage/view to that script. Firefox won't let me attach this file so here are the contents of it and you can update it manually:

RewriteEngine On
RewriteRule adoptimage/view/([0-9]+)$ adoptimage.php?id=$1 [L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !\.(js|css|html|xml|json|gif|jpg|png|ico)$ [NC]
RewriteRule ^(.*)$ index.php [QSA,L]
RewriteRule ^get/([0-9]+).gif$ /click/siggy/$1 [L]

Finally, to fix an issue I was seeing with the adoptable model, I had to add properties for the newly defined columns in model/domainmodel/adoptable.php. I also updated it to use AllowDynamicProperties since the number of markings may change over time.

At this point the images are generating for me, but I'm not seeing the correct color applied, even though I am seeing that it has the expected hex value when it goes to call evaluateImage().

I don't know if this is an issue with the images I'm using or what, so when you run this, let me know how your image comes out.

I updated the files but nothing is generating for me for some reason... do I need to delete the original files?

 

[T1K]

I updated the files but nothing is generating for me for some reason... do I need to delete the original files?

It looks like it's routing to the new file (example) but probably encountering some errors, judging from the result. I know that I saw an error earlier with the example URL, but then after refreshing it shows the broken image that it is now returning.

I'm wondering if that first request returned an error because of some PHP error or warning getting into the output. I've attached an updated version of the adoptimage.php file that should hopefully help us to diagnose that issue, assuming we can reproduce it.

Other adoptables I've tried to test this script on so far (example) are at too low of a level to show anything, so we get an empty image in that case. After you've uploaded the updated file, could you also go into the DB and update the adoptables with IDs 2 through 4 so that they're level 1, and marked as ready for an image update? You can use this query to do so:

UPDATE `adopts_owned_adoptables` SET `currentlevel` = 1, `lastupdate` = NOW() WHERE `aid` BETWEEN 2 and 4;

Could you also upload your picuploads directory so I can play around with the image generation logic locally? I'm hoping that this will make it easier to figure out why the resulting image is malformed once it does get past that initial error.

 

[emotidogzz]

It looks like it's routing to the new file (example) but probably encountering some errors, judging from the result. I know that I saw an error earlier with the example URL, but then after refreshing it shows the broken image that it is now returning.

I'm wondering if that first request returned an error because of some PHP error or warning getting into the output. I've attached an updated version of the adoptimage.php file that should hopefully help us to diagnose that issue, assuming we can reproduce it.

Other adoptables I've tried to test this script on so far (example) are at too low of a level to show anything, so we get an empty image in that case. After you've uploaded the updated file, could you also go into the DB and update the adoptables with IDs 2 through 4 so that they're level 1, and marked as ready for an image update? You can use this query to do so:

UPDATE `adopts_owned_adoptables` SET `currentlevel` = 1, `lastupdate` = NOW() WHERE `aid` BETWEEN 2 and 4;

Could you also upload your picuploads directory so I can play around with the image generation logic locally? I'm hoping that this will make it easier to figure out why the resulting image is malformed once it does get past that initial error.

So from the output marking24 and marking 25 aren't getting colored. Every other marking appears normal (although the big test will be if the image merge works when breeding adopts). From that fix, the myadopts/manage is showing the image but not the thumbnail on other pages.

I'll update those for you, it's just a bit of a pain because I have to manually input each color in the database lol... but it'll show if marking24 and marking25 aren't working on all of them. I'm going to disable the adopting through the adopt new pets page eventually since they'll end up being blank in the database... too much of a pain.

I'll start updating those now.

edit: where do I put the sql once I've done that?

 

[T1K]

So from the output marking24 and marking 25 aren't getting colored. Every other marking appears normal (although the big test will be if the image merge works when breeding adopts). From that fix, the myadopts/manage is showing the image but not the thumbnail on other pages.

I'll update those for you, it's just a bit of a pain because I have to manually input each color in the database lol... but it'll show if marking24 and marking25 aren't working on all of them. I'm going to disable the adopting through the adopt new pets page eventually since they'll end up being blank in the database... too much of a pain.

I'll start updating those now.

edit: where do I put the sql once I've done that?

Sorry for the late reply, I was back to work this week and usually don't have much mental energy at the end of the day to do more programming related stuff.

re: the thumbnail not displaying on other pages, are the thumbnails' src pointing to the /adoptimage/view URL now too? For example, when I looked at an image source on /myadopts, I noticed what looks like this issue again: https://forums.mysidiaadoptables.co...cally-generated-images.4333/page-3#post-33242

As for the marking colors, yeah, it'd probably be good to add some logic at some point to populate those fields when the adoptable is adopted. Maybe we can try to tackle that part next because otherwise you'll have this issue with every adoptable if I'm understanding it correctly.

You can probably use phpMyAdmin to input the other SQL, I haven't used it in a while but I imagine there's an SQL input option that will let you run the query. (You could probably also use this to make updating the markings faster in the meantime until there is some logic to auto-populate it.)

 

[emotidogzz]

Sorry for the late reply, I was back to work this week and usually don't have much mental energy at the end of the day to do more programming related stuff.

re: the thumbnail not displaying on other pages, are the thumbnails' src pointing to the /adoptimage/view URL now too? For example, when I looked at an image source on /myadopts, I noticed what looks like this issue again: https://forums.mysidiaadoptables.co...cally-generated-images.4333/page-3#post-33242

As for the marking colors, yeah, it'd probably be good to add some logic at some point to populate those fields when the adoptable is adopted. Maybe we can try to tackle that part next because otherwise you'll have this issue with every adoptable if I'm understanding it correctly.

You can probably use phpMyAdmin to input the other SQL, I haven't used it in a while but I imagine there's an SQL input option that will let you run the query. (You could probably also use this to make updating the markings faster in the meantime until there is some logic to auto-populate it.)

No worries! Sorry as well - life got in the way lol. I am planning on starting a new site (already have it set up) just not looking forward to all the work getting the code working lol. If I run into an issue I'll mention it here.