Pages Category Images / Pages Searchable Text Fields

[All Astronauts]

Pages Searchable Text Fields is fine on 4.7 - I resubmitted a new 4.0.0 version to the Marketplace so I could flag the file out as 4.7.x compatible, but other than the version number the plugin is the same - though I think in the next version I'll stick a flag in on database fields view so you can see that a field is flagged as searchable or not. 

Looking at PCI now, should be back here in a bit...

[All Astronauts]

Pages Category Images is good to go as well. Upgrade away.

I did submit a new version to the Marketplace - 4.1.0 - the only change is adding in a template that displays beneath the image upload field providing the ways you can use this stuff - and of course flagged the file out for 4.7 compat.

[EvanDC]

Hi - newish user here! 
I bought this add on a week or so ago, when I think I was still on my trial account (maybe - can't honestly remember). I'm now on a paid package on the lowest tier which I know doesn't have database access (which is tbh hugely annoying). 

This add on WAS working just fine, but today I got a red flag on my applications tab and went looking to see what it was for. The only thing I can see is that this add on is now greyed out for some reason, but nothing further to tell me why. 

Could it be that I don't have database access anymore? I upgraded over a week ago from the trial to the paid package. But only today has this application warning flag appeared. 

Any thoughts or pointers? 

[All Astronauts]

@EvanDC Strange. PM me ACP access and I can take a peek. The current version of PCI does not get flagged by the PHP 8 checker in 4.7.5, and there are no change notes in 4.7.6 that would indicate something breaking. And that's the only direct reason I can think of to have the app disabled.

No matter, PM me creds and I'll poke it with a stick.

[All Astronauts]

@EvanDC and others: PCI is fine.

If you are on CIC, and are on the Creator package, you can enjoy access to the Pages application. 

But only for making "pages" and the default Pages - Article database.

If you want to make your own databases, you'll need to increase your IPS spend to the next level - Creator Pro. 

But in either case, PCI is fine. If you are limited to just Articles, PCI still works.

[EvanDC]

Ok - I'll be honest, one of the things - as a new person learning a complex ecosystem, language and framework here, I know all these things make sense to you long term users ... but there is ZERO transparency on this in the marketplace. It may sound really dumb of me, but there's virtually nothing to tell me that buying a certain app REQUIRES the next tier up from what I have. This is an annoyance factor. I love the platform, I really do ... but I don't love the fact that databases are ONLY properly available on the Creator Pro package, or that certain items in the marketplace NEED Creator Pro to function, or that I can buy items which are not actually compatible with my tier of product. That side of things, from a newbie's point of view, is a bit of a mess. 

 

[EvanDC]

What is CIC? 

[opentype]

It’s an annoyance for us too. IPS has just recently started to remove options from lower tiers and change their plans several times in a single year. Not much we can do about it. 

In general, if you are unsure, you can always ask upfront in the support topics for the products. We can only describe the products. If it says it’s for “Pages databases”, it clearly describes that Pages databases are required, but of course you need to understand what that means. If not, please ask. 

[All Astronauts]

Community in the Cloud, the IPS hosted version of the software which you are on.

@IPS - CIC would make for a really good use of your built-in Word Expansion feature on this site.

And as @opentype said, it's not the best clarity anymore - instead of explicitly stating the app and major feature available per-package, it's abstracted out with marketing-speak. When viewing the options on the pricing page you'll notice a number of options are actually clickable and expandable. You'll get more details there.

 

[CheersnGears]

On 2/6/2019 at 5:23 AM, Meddysong said:

A tip for people using Pages Category Images and getting broken images.

When I started using it, $category->pcimage and {file="$category->pcimage"} were producing full URLs but <img src='{file="$category->pcimage"}'> was only stopping at my Amazon S3 bucket; it didn't contain the full URL with the filename and extension. When I pasted the full URL into my browser, I got an error message.

The reason is because URLs were being created to my Amazon S3 account, which is where I store my Pages media. Pages Category Images has its own setting in  System > Overview > Files > click Storage Settings, which by default is set to file system, using the server where the suite is installed. This means that my category images were being uploaded to a place on my server whilst the system was looking for them on my S3 account alongside the other Pages media.

I solved the problem by changing the storage method of Pages Category Images to S3 and within seconds the images were displaying.

 

On 2/6/2019 at 2:19 PM, All Astronauts said:

Yeah, hmm. Not sure there is an easy way here. I'll have to look. Maybe I can ditch this and ride on the official Pages one. Otherwise, yeah, you need to match the two.

This has been driving me a bit nutz today.

Initially, I left the file location for this app unconfigured, but then @opentype's SuperGrid couldn't find the attachment because it was looking in my attachments directory.

I moved everything from the attachments directory to the uploads directory, and things worked. So, because I prefer to keep things tidy, I moved everything back to the attachments directory AND set the directory for Pages Category Images to the same attachments directory, and now neither this app nor Pages Supergrid points to the correct file.

I can upload a file to the category, but the preview is immediately broken. If I copy the URL to another tab but remove the attachments folder from the URL, the file loads, which means it uploaded correctly but not to the directory it is supposed to upload to.  So, somewhere, somehow, this app is not respecting the file location settings under Storage settings in ACP.

My site is 20+ years old, so I really don't like dumping everything in Uploads.

[All Astronauts]

@CheersnGears timing is everything and with all the yelling and such regarding my S3 compatible uploads plugin and I can test this now-ish as that's getting a re-engineer. I'll move things around between local and remote storages and see if this bugged somehow.

[CheersnGears]

Just now, All Astronauts said:

@CheersnGears timing is everything and with all the yelling and such regarding my S3 compatible uploads plugin and I can test this now-ish as that's getting a re-engineer. I'll move things around between local and remote storages and see if this bugged somehow.

Thanks, I have more information to add for you in a few minutes. I'm testing some current settings with fresh files to make sure I'm not polluting new tests with old files.

[CheersnGears]

9 minutes ago, All Astronauts said:

@CheersnGears timing is everything and with all the yelling and such regarding my S3 compatible uploads plugin and I can test this now-ish as that's getting a re-engineer. I'll move things around between local and remote storages and see if this bugged somehow.

This is quite the rabbit hole today.

Using the constants.php settings recommended by @Matt here

\define( 'IPS_FOLDER_PERMISSION', '0777');
\define( 'FOLDER_PERMISSION_NO_WRITE', '0755');
\define( 'IPS_FILE_PERMISSION', '0666');
\define( 'FILE_PERMISSION_NO_WRITE', '0644');

And then looking in FTP, I find that the file gets uploaded with permissions of 1232, which of course means the file can't be read by Apache.

Now, I added those settings today because for some reason the IPS file move process borks folder permissions on my server and the upload folder ends up unwriteable.

If I take those lines out of constants.php, then both your app and opentype's work properly when both are set to my attachments folder. So, I think your app has to always match whatever is set in the Attachments location for Supergrid to work.

So I guess I'll leave it as is for now and I'll just have to remember that I can never move files under storage settings without putting those lines in first.  I really don't understand how that IPS permissions issue is happening since I have a bone stock AlmaLinux + CPanel setup. Absolutely nothing special and none of my other site installs with other software have this issue.

If you want any troubleshooting feedback from my end, I'm happy to help and test.

[All Astronauts]

@CheersnGears

Well that's some interesting file permissions. That permissions number ain't in the suite anywhere that I can find, including my apps, so where that's coming from :shrug:

Anyhoo... So, one of the things I did with the last version was touch up the documentation and such, including adding it to the add image tab in the ACP itself. And... ummm... I might, MIGHT..., maybe, left a bit off the file call there. Probably.

{file="$category->pcimage" extension="pci_PagesCatImages"}

You need the extension there otherwise it will flail about and so on.

I tested moves to Wasabi from local, confirmed it moved fine, deleted the local copy fine, but the url in the article page was still wrong. The file is stored with only the folder/filename in the db, so that was fine, that left why it wasn't getting the actual web storage url correctly and well..., etc. etc...

Touch up your insertion code to have the extension= bit as seen above, and you should be fine, excepting whatever the hell is going on with your actual uploads and permissions.

 

[CheersnGears]

1 hour ago, All Astronauts said:

@CheersnGears

Well that's some interesting file permissions. That permissions number ain't in the suite anywhere that I can find, including my apps, so where that's coming from :shrug:

Anyhoo... So, one of the things I did with the last version was touch up the documentation and such, including adding it to the add image tab in the ACP itself. And... ummm... I might, MIGHT..., maybe, left a bit off the file call there. Probably.

{file="$category->pcimage" extension="pci_PagesCatImages"}

You need the extension there otherwise it will flail about and so on.

I tested moves to Wasabi from local, confirmed it moved fine, deleted the local copy fine, but the url in the article page was still wrong. The file is stored with only the folder/filename in the db, so that was fine, that left why it wasn't getting the actual web storage url correctly and well..., etc. etc...

Touch up your insertion code to have the extension= bit as seen above, and you should be fine, excepting whatever the hell is going on with your actual uploads and permissions.

 

I'm not really a coder, so all I'm doing is using @opentype's app. But this is what I found in his SuperGrid categoryRow template.

{{if $category->pcimage}}<div class="SG_cat_image" style="background-image:url('{file='$category->pcimage'}');"></div>{{endif}}

I'm guessing he'll need to update.

[All Astronauts]

Just now, CheersnGears said:

I'm guessing he'll need to update.

Yep, if that is coming directly from those templates and you didn't change them (I did not know he was directly supporting this app in that stuff). You *can* change them in your theme, but when upgrades come around then you have to deal with them maybe updating, maybe not as they will then be flagged as "modified".

Either way, a miss on my part with the docs. It's clearly there in the template tags stuff in the official IPS documentation here; I just spaced them when including same in my app description and inside my app itself.