X3Photo Gallery Forums

Bulletproof IT · 03 Aug 2013, 15:38

Hello

I get quite frustrated with scripts that decide to mess around with text.

For example, typing in <p style="Font-Family: Verdana, Tahoma;">
once saved became: <p style="font-family" verdana="" tahoma="">

DIV was more successful, but I had to then place the DIV's outside of the Paragraph, as it kept moving the tags around.

I have opened up the COLOR.CSS file which is in use, and cannot determine which tag is responsible for the text page styling. None of the Text page tags, when updated to 28px in font-size, do nothing to the output of the page.

Could someone please provide a definitive solution to this?

Thank you greatly!

04 Aug 2013, 05:00

Bulletproof IT wrote:For example, typing in <p style="Font-Family: Verdana, Tahoma;">
once saved became: <p style="font-family" verdana="" tahoma="">

That is unfortunate, however: A) It would not work like this in flash textfields anyway, as they don't support inline styles like that. B) Why set font directly in the html anyway? It should be done in CSS to maintain global styles.

Bulletproof IT wrote:I have opened up the COLOR.CSS file which is in use, and cannot determine which tag is responsible for the text page styling. None of the Text page tags, when updated to 28px in font-size, do nothing to the output of the page.

Where did you get color.css from? This is not even an existing file in Imagevue. ALL styles for texts in the flash image gallery, are handled by your theme CSS stylesheet file (normally imagevue.css) ... you can edit it directly from theme editor in your admin. Here is the full guide:
https://www.photo.gallery/documentation/cssreference/

Search "textpage" to see how to edit textpage styles. Here are the ones you should be editing:

.textpage{ 
/*Sets global styles for all items in the textpage*/ 
} 
.textpage_title{ 
/*Sets styles for the title of the textpage*/ 
} 
.textpage_body{ 
/*Sets styles for the main body/content of the textpatge*/ 
}

When you save an edited stylesheet, you may need to empty your browser cache to view changes, since CSS stylesheets are often cached in your browser.

Bulletproof IT · 05 Aug 2013, 23:46

If you click on either of 2 specific themes, you can change the dropdown for the css file in use.
By default two themes come with imagevue.css and color.css - carbonizer and lucdido from memory...

I am making changes in CSS. But they are not being displayed. I said in my message before I tried all the "Textpage" css values, but none of them do anything.
e.g. font-size:28px; and font-size:28;

Neither of them do anything.

So could you please help me change the size of the text in the css file, which I have already tried doing (see original message).

I have opened up the COLOR.CSS file which is in use, and cannot determine which tag is responsible for the text page styling. None of the Text page tags, when updated to 28px in font-size, do nothing to the output of the page.

Could someone please provide a definitive solution to this?

Thank you.

p.s, Still on v2.8.9 as 2.8.10+ causes issues

06 Aug 2013, 02:39

Bulletproof IT wrote:If you click on either of 2 specific themes, you can change the dropdown for the css file in use.
By default two themes come with imagevue.css and color.css - carbonizer and lucdido from memory...

Hmm you are right but it should not be like that. You should be editing "imagevue.css" and color.css should not be available ... We are looking into this ...

Bulletproof IT wrote:I am making changes in CSS. But they are not being displayed. I said in my message before I tried all the "Textpage" css values, but none of them do anything.
e.g. font-size:28px; and font-size:28;

Neither of them do anything.

After editing "imagevue.css"? After saving, either you will need to empty your browser cache, or use chrome "incognito" window so that it loads CSS instead of using cached css. It will work if done correctly, please send me a link for reference where changes are not showing.

Bulletproof IT wrote:p.s, Still on v2.8.9 as 2.8.10+ causes issues

What kind of issues?

Bulletproof IT · 07 Aug 2013, 13:27

mjau-mjau wrote:
Bulletproof IT wrote:If you click on either of 2 specific themes, you can change the dropdown for the css file in use.
By default two themes come with imagevue.css and color.css - carbonizer and lucdido from memory...
Hmm you are right but it should not be like that. You should be editing "imagevue.css" and color.css should not be available ... We are looking into this ...

mjau-mjau wrote:
Bulletproof IT wrote:p.s, Still on v2.8.9 as 2.8.10+ causes issues
What kind of issues?

G'day mate,
Well I've finally managed to get 2.8.10.x installed. No longer using a dodgy old version

As discussed previously, you said Imagevue doesn't play friendly with Suhosin. I still have the Triangle, but everything appears to work

RE: CSS
It looks like they should be there. If you change it, and click SAVE. Then view the gallery - you get these great colours on elements which make them stand out... A great way to start customising and creating your own "color1.css"

I guess it operates as an "Override", so that without changing the core CSS, you can simply edit the Color CSS and it overrides the defaults.

Please don't remove this functionality or the files in future versions! It is incredibly useful. (mind you I find things a little eratic - filename.css >> "Filename.css". And cloning a theme as "ExampleTheme" >> "Exampletheme". It is obviously minor, but may cause issues on Windows systems which are case sensitive.)

Keep up the great work!
p.s. update your blog

Question:
I'm finding when resizing all images in an album, that the photos are not "complying" to the resize. They look fine in the backend! The images are all in a portrait aspect ratio. However on the front end, only some will save or accept the batch resize of photos. So some are still the old thumbnails, and others are in the new resolution.

Options: Re-create thumbnails, Crop-to-box...
e.g. 150x200px with the 6 included example images, all larger than the thumbnail dimensions.

Screenshots:
- Admin: http://i.imgur.com/PmGJwRk.png
- Front: http://i.imgur.com/bpiKBrr.jpg

File Permissions: 3 photos reside in Pictures 1. I moved the 3 people into Pictures 1. The people photos (originally Pictures 2) have CHMOD 0666 (inc thumbnails). Whilst the original images in the folder have CHMOD 0755 (inc thumbnails).
Previewing "tn_tiger.jpg" it has the correct 150x200px dimensions. Having cleared cache it still appears as old resolution. So this must be due to Imagevue setting the default permissions to files/folders upon initialisation.

Fixed: Changed permissions manually and flushed. Might be something to add to the to-do list.

(i.e. expiry of data, so it is refreshed - as 3 original files did not update, whilst 3 files previously copied in, then viewed gallery, and THEN resized images. Despite having viewed all images in original small size, the 3 files moved, with different permissions appear to update in cache immediately.
>> You cannot expect all your visitors to be flushing their cache, to view the site without error, so you simply cannot have flushing cache as solution... No visitors are going to do this between visits.
>> Fixing permissions of original files, on initial load or something. So that permissions are consistent.

Thank you.

08 Aug 2013, 06:29

Bulletproof IT wrote:I'm finding when resizing all images in an album, that the photos are not "complying" to the resize. They look fine in the backend! The images are all in a portrait aspect ratio. However on the front end, only some will save or accept the batch resize of photos. So some are still the old thumbnails, and others are in the new resolution.

Options: Re-create thumbnails, Crop-to-box...
e.g. 150x200px with the 6 included example images, all larger than the thumbnail dimensions.

Screenshots:
- Admin: http://i.imgur.com/PmGJwRk.png
- Front: http://i.imgur.com/bpiKBrr.jpg

That is just your browser cache ... It works in the admin because it force-refreshes the thumbnails. Empty your browser cache and you will see correct thumbnails! It also would show 3 thumbnails correct because they were created in the first place at that size, while the "original" thumbnails have been pre-cached in your browser when viewing the gallery before you changed anything.

Bulletproof IT wrote:File Permissions: 3 photos reside in Pictures 1. I moved the 3 people into Pictures 1. The people photos (originally Pictures 2) have CHMOD 0666 (inc thumbnails). Whilst the original images in the folder have CHMOD 0755 (inc thumbnails).
Previewing "tn_tiger.jpg" it has the correct 150x200px dimensions. Having cleared cache it still appears as old resolution. So this must be due to Imagevue setting the default permissions to files/folders upon initialisation.

Fixed: Changed permissions manually and flushed. Might be something to add to the to-do list. (i.e. expiry of data, so it is refreshed - as 3 original files did not update, whilst 3 files previously copied in, then viewed gallery, and THEN resized images. Despite having viewed all images in original small size, the 3 files moved, with different permissions appear to update in cache immediately.

This is just your browser cache, nothing to do with permissions. The fact that the "original" files uploaded by FTP have different permissions than files uploaded through the admin, is normal. The permissions set on your admin-uploaded files is the correct permissions.

Bulletproof IT wrote:>> You cannot expect all your visitors to be flushing their cache, to view the site without error, so you simply cannot have flushing cache as solution... No visitors are going to do this between visits.

Old cache files are only in YOUR browser, not in visitors. New visitors will see new thumbnails. In regards to resizing thumbnails, I am not sure why this is an issue ... you should be setting thumbnails when adding the gallery for the first time ... there should not be any logical reason to wish to swap thumbnail size/aspects frequently.

Bulletproof IT wrote:>> Fixing permissions of original files, on initial load or something. So that permissions are consistent.

Permissions are ALWAYS consistent in regards to files and folders created from your admin. In fact, Imagevue does not set permissions ... Instead, if your server is set up correctly, permissions are set based on what they should be so that the PHP can interact with them and make them visible to the public. Neither does Imagevue have anything to do with permissions when you upload files, this is just your default permissions when uploading by FTP.

Bulletproof IT · 09 Aug 2013, 09:48

Thanks for your response. I appreciate your time answering my queries.

However I haven't uploaded any files. I was just doing a test with a 2nd install in a sub-folder /beta/
So all files are yours. Your demo photos. All I did was, from within Admin, select the 3 images from /Pictures2/, select MOVE to the /Pictures1/ folder with 3 existing files.

Example One
A). All Files 755 - Note: lyon.jpg (Thumb: 150 x 200):

B). Moved LYON.jpg city photo to /Text Page/ via Admin, then Moved it back to /Pictures1/ via Admin (no resizing, just moving):

_____________________________________________________________-

Example Two
1). Resize Photos in Album (e.g. 152 x 200):

2). Switch to Front-end, ack! Photos are overlapping!:

3). Change Permissions of ALL Files Manually via FTP to 0666:

4). Refresh Front-end, without any Clearing of Cache - Woohoo!:

5). Then Resize to Back to Old Resolution (e.g. 150 x 200):

6). Then view front-end, without clearing cache -

Wooohoo!:

Perfect! No problem!

I've no idea why it now works after setting all File permissions from 0755 to 0666...
I'll let you know how it goes over time.

?? Perhaps a better solution, would be to set an expiry for thumbnail content. e.g. 3 days, 7 days, 14 days, etc.

QUICK QUESTION:
On both Thumbnail generation and Image upload resizing, what is the default "Quality" level used within ImageVue when resizing and/or creating JPG files?
Can this be changed?
Which file(s) are responsible for quality of files via Thumbnail Generation?
Which file(s) are responsible for quality of files via Image Upload?

Thank you. Much appreciated.

Bulletproof IT · 10 Aug 2013, 02:35

<IfModule mod_headers.c>
    # MONTH
    <FilesMatch "\.(jpg|jpeg|png|gif|ico|flv|swf|fla|mp3)$">
       Header set Cache-Control "max-age=2592000"
    </FilesMatch>

    # WEEK
    <FilesMatch "\.(js|less|pdf|txt|rtf|ini)$">
       Header set Cache-Control "max-age=604800"
    </FilesMatch>

    # DAY
    <FilesMatch "\.(html|htm|css)$">
       Header set Cache-Control "max-age=43200"
    </FilesMatch>
</IfModule>

Note: See the "Day Expiry" of CSS above.

Perhaps a "tn_" prefix could be added to Day for expiry of thumbnails after 24 hour period...?
I would have to create a new FilesMatch for "tn_" . "gif, jpg, png". This may look something like this:

<FilesMatch "^(tn_|th_|thumb_)\.(jpe?g|png|gif)$">

So would this work - the concept and addition of the above code to the htaccess file?? (I forget if it is "jp?eg" or "jpe?g"...)
I would hate to break something!

Would these entries and values be inherited into ImageVue?

Now, just to sort out the issue of which file(s) are responsible for quality of Images via Thumbnail Generation + Image Upload.... Hmmm....

As always, thank you very much for your time.

11 Aug 2013, 11:34

What exactly do you mean "expiry of thumbnails" ... You mean you want to force browsers to re-load "latest" thumbnail from server instead of loading the cached one? I don't see why that has any benefit unless you like to frequently change size of thumbnails, which I can't see any need for.

Looking through some of the screenshots above, I can still say the ones that have incorrect layouts are cache issues to some degree ... its nothing "wrong", you just need to dump cache and refresh pages. Cache can span through many elements: your browser, proxy server, home-server and also the file that stores max/min thumbnail sizes, which also decides the spacing between thumbnails. Layout issues can also get further complicated if you choose to resize some thumbnails in a folder, but not all ... I could show this if you had an online version with link ...

Not sure on your local server why this is related to permissions, but it could be it is affecting the browser caching mechanism in some way, but in general this is entirely unrelated.

I don't quite see why you want to change expiration times for cache. Cache is a good thing. If you make any changes to your gallery in thumbnails or CSS, all new visitors will see the changes you made ... only you the admin/editor will experience cached files, and that can easily be fixed by simply emptying your cache, or even better: preview changes in "private" browser tab (In chrome its called "incognito tab"), which force-reloads all files from server.

Thumbnail quality is set to 98, which sets them on high quality and file sizes are not big anyway. I doubt you would find it useful changing this.

Nick · 11 Aug 2013, 11:45

Before we had JPEG quality setting in config but have removed it a while ago since it seemed redundant. So now you would have to patch files as follows.

Quality setting for Uploader (if you choose to resize images on upload):

# iv-admin/assets/js/imagevue.upload.js:7

Imagevue.Environment.resizeQuality = 95;

Quality for thumbnails:

# iv-includes/include/ivImage.class.php:16

const DEFAULT_QUALITY = 95;

Bulletproof IT · 17 Aug 2013, 22:40

Nick you are BRILLIANT!

That is incredibly useful. (10 x Smiley's)
Thank you! I'm your new #1 fan.

I guess the only question left, is how the Quality can be changed in the "Thumbs" thumbnail resize tool? (post-upload)

I would even be happy to contribute a little to someone's retirement fund, if I could:
- control thumbnail resizing inheritance - e.g. Enable / disable sub-albums from being resized with root files (current folder only, or current folder and sub-folders).

Mjau-Mjau,
I totally understand that cache is a good thing. However certain files over a period of time should be kept and retained over other files to prevent a stale cache.

If a visitor visits every 1-2 days, then their cache will also affect the display of the website... Not just mine or the client administrator. Clearly it would be important to cater for all types of sites and customers and their needs. There must be a way to mark an album as "dirty" once images have been modified from last cached visit? i.e. then comparing the cached 'salt' or checksum and if different, transmitting the new files.

All the best,

18 Aug 2013, 03:21

Bulletproof IT wrote:Mjau-Mjau,
I totally understand that cache is a good thing. However certain files over a period of time should be kept and retained over other files to prevent a stale cache.

If a visitor visits every 1-2 days, then their cache will also affect the display of the website... Not just mine or the client administrator. Clearly it would be important to cater for all types of sites and customers and their needs. There must be a way to mark an album as "dirty" once images have been modified from last cached visit? i.e. then comparing the cached 'salt' or checksum and if different, transmitting the new files.

You are saying it as if Imagevue controls the cache. Imagevue in fact makes sure to server all fresh changes to the page, folder and also image data. However, loaded image files are cached by your browser, unrelated to Imagevue ... Its not like Imagevue can choose to empty browser cache for the visitor or anything. The only possible technical implementation, would be to add random strings to the URL like this filename.jpg?87654567 which basically just tricks the browser into thinking its a new file ... this is considered poor implementation though. Imagevue does not cache files in any way.

Bulletproof IT wrote:If a visitor visits every 1-2 days, then their cache will also affect the display of the website...

As mentioned, Imagevue does not cache any pages or data, and will always server the latest information. The only possible scenario would be if you are resizing thumbnails ... How often are you doing this? Normally, it would be one time and they stay like this forever.

Bulletproof IT wrote:However certain files over a period of time should be kept and retained over other files to prevent a stale cache.

Still a bit uncertain what you are referring to here ... Imagevue does NOT serve cached page data. Image files (from any web image application), get cached by your browser ... It is then the browser policy that decides if the cached file is stale and if it should load a new one (from your server).

Bulletproof IT · 11 May 2014, 15:40

Hi again

Hmm well I have never ever ever ever in my life seen a Flash website show cached content. e.g. Thumbnails at wrong dimensions,
Clearly the page needs to TELL the browser to dispose of the cached files after a period of time. This is what I've said from the start.

I think you've missed everything I've discussed. The point is I CANNOT tell every visitor to empty their cache when visiting.

It is so simple. I don't know how you're missing it.

Try it yourself.
Visit a gallery. Go through several pages of thumbnails.
View a few dozen images in the slideshow mode.
Now go to the backend.
Resize the albums thumbnails for example to a different proportion - landscape or square or portrait.

Now visit the same gallery!
Everything is overlapping in thumbnail view!

Clear cache. Refresh. Wow. Everything is fine!

You cannot tell that visitor to now flush their entire cache.

If $last.visit > $last.resize.date, then serve fresh content, else use cached files.

12 May 2014, 01:40

I am not quite sure why we are discussing a 1 year old post here, but anyway ...

I don't disagree with the technical aspect of what you are saying, but just let me make one thing clear: It is the BROWSER that is caching thumbnails, NOT Imagevue in any way. Furthermore, it is entirely irrelevant if it is Flash or HTML, because both just make plain http calls to load an image, and thats that. If you never heard of a Flash website showing cached content, then well you aint seen much flash. Browsers are SUPPOSED to cache, and luckily this is a feature that is not automatically voided by flash ... Having said that, I am very happy to move away from flash to html for Imagevue X3.

There are some remedies we could integrate to solve your problem:

A) The flash file add a random string behind every thumbnail call tn_filename.jpg?432523523, which will force the browser to load a new version of the thumbnail. Of course, really bad practice to force refresh of files and hi-jack the browsers native caching.

B) There may be some methods to apply to your .htaccess file on server, which will first check if the file has changed, and report to browser. Browser will only reload the image, if the file has changed and has a different date than your browsers cached version. We are looking into this in Imagevue X3.

C) You could hack it for now, and rename the folder (keep the same title of course). That means the load path will change, and force the browser to reload images.

Apart from the options above, I don't know what you are suggesting ...

Bulletproof IT · 12 May 2014, 05:20

Excuse me? I don't know why you're being so rude. Would you prefer I create a new topic for every question? I am not quite sure why you still can't read what I've written! You keep telling me I'm talking about something that I am not! I've read back over my past few messages - no where does it say I am talking about the server. Everything I discuss is the visitor and browser!
The reason I am responding is that you have not made any updates to the application, so nothing has changed! Why fill the forum with duplicate topics?

I am trying to be constructive here. I am trying to resolve an issue that clearly is affecting people, otherwise I would not be wasting my time looking for a solution! I don't want conflict. I just want a solution.

If $last.visit > $last.resize.date, then serve fresh content, else use cached files.

What .htaccess modifications do you suggest? RE: Part B. in your message.

You still don't understand what I am saying. Your entire message, excluding B)., has got nothing to do with what I have said (or ever said!). Show me WHERE I have said "The Web Server Performs All Caching"??
I have said a hundred times, that the VISITOR / BROWSER is caching. Read my message. It is in black and white.

Hmm well I have never ever ever ever in my life seen a Flash website show cached content.

That is because the BROWSER does the caching! That is why there is a Clear Cache button in ALL browsers! Read what I said - "I have never seen a website show cached content!" Is that not clear?

Clearly the page needs to TELL the browser to dispose of the cached files after a period of time. This is what I've said from the start.

Read what I am saying. The PAGE (imagevue) needs to TALK to the BROWSER, to then dispose of the cached files! How is this hard to understand? Where am I saying the SERVER is doing the caching? You really have to slow down and read what people say. So much time has been wasted where you're not reading what I've said.

Clear cache. Refresh. Wow. Everything is fine!

Guess what! The Clear Cache button does NOT clear the cache of the web server!!! It clears the BROWSER cache!

You cannot tell that visitor to now flush their entire cache.

Again, read what I am saying! The VISITOR cannot be expected to clear their cache every time they visit a website!

Why are we going around in circles 9 months later? Please slow down and read what people say, instead of jumping to conclusions. You may find out, that they actually know what they are talking about.

X3Photo Gallery Forums

Help - Changing Styling on Text Pages - Why is it so hard?16 postsPage 1 of 2

Help - Changing Styling on Text Pages - Why is it so hard?

Re: Help - Changing Styling on Text Pages - Why is it so har

Re: Help - Changing Styling on Text Pages - Why is it so har

Re: Help - Changing Styling on Text Pages - Why is it so har

Re: Help - Changing Styling on Text Pages - Why is it so har

Re: Help - Changing Styling on Text Pages - Why is it so har

Re: Help - Changing Styling on Text Pages - Why is it so har

Re: Help - Changing Styling on Text Pages - Why is it so har

Re: Help - Changing Styling on Text Pages - Why is it so har

Re: Help - Changing Styling on Text Pages - Why is it so har

Re: Help - Changing Styling on Text Pages - Why is it so har

Re: Help - Changing Styling on Text Pages - Why is it so har

Re: Help - Changing Styling on Text Pages - Why is it so har

Re: Help - Changing Styling on Text Pages - Why is it so har

Re: Help - Changing Styling on Text Pages - Why is it so har