Search…

X3 Photo Gallery Support Forums

Search…
 
User avatar
sprocket
Experienced
Topic Author
Posts: 98
Joined: 18 Dec 2008, 19:40

Some Concerns

08 Nov 2015, 10:46

I love what we are seeing in X3's development. I especially love how manipulative the website pages can be on such a low level (like customized html, css, java, etc.). It's also great where you have recently taken the software. To a place where the less tech-savvy people can get in the game and use it to create their own pages with greater ease. All this while still while keeping things customizable. I do have one concern which has personally worried me since the start of X3. It involves the current menu structure and links. I will try to explain.

Menus are structured such that, by adding prefixing them with numbers will result in that menu item being publicly viewable and positioned in that numbering order. While I have no real problem with this concept (except that it actually creates more work for me), the majority of the real issue are currently rooted with the lack of relative paths within the content area of the pages system. Even in the current version, I see no way of linking a photo (for example) from the current folders gallery in the content area with using an absolute link. The problem with these links is that if a person then decides to rearrange his/her menu listing, all the links will fail, because the menu name (with the number) is part of the link. This is very easy to see in the current version release.

For example, the first things I wanted to do when testing the new version, was to put my menu items first (on the left), so I could easily play around and test things. I don't want to hide the examples just yet, but I want them moved to the right so I can refer to them as needed. So I rename the default menus, for example 10.galleries and 11.examples. From there, it doesn't take long clicking through the galleries and examples pages, to see the endless links that fail because 1.galleries and 2.examples are all hard coded (absolute) in those content sections. This is the exact same type of content that I personally would like to create also, but without the failing links issue when I want to reorder menus.

I don't have the answer here, I just know I'd like to have the freedom to move menus around and arrange when the mood strikes. Sometimes I never feel I have things where I want them. I know spacing out the prefix numbers would help with this issue, but it's not a real answer. I would like to be able to move things without constantly having to worry about what's not gonna work next. This is where the real need for relative links is needed. If we could either use things like ./photo.jpg to refer to a current folders photos. Or be able to hop across directories (classic relative style) for example if we were in a folder called 2015 and wanted to jump to the 2014 folder (both under the same parent), something like ../2014/photo.jpg (up to parent then down adjacent folder. OR maybe if there was a way to eliminate the numbers in the actual links, so that changing the number wouldn't affect the link. Something like /galleries/food/photo.jpg, although I personally believe the "industry standard" relative links format give the most power and freedom, especially the double dots "../" (parent) which allows climbing the directory tree.

Here's another example I find myself in all the time. When I create a new page, I don't want the world to see it, so I give it a name like 'travels", without a number so it's hidden. I now go in and upload photos and create content describing the pictures that will be in the gallery, by including a couple photos in the content to make the read easier on the eyes. Some teaser photos if you will, to lead the viewer through the read and into the gallery. So right now I have to use absolute links to get those photos to show. But the name 'travels', will not be the final name of my menu listing. It will eventually need a number to place it and allow the world to see it. So this means all the photos (within the content) I've added for creation purpose, are actually all gonna fail the second I give my menu a name like '5.travels'. When the page is finished and ready to publish, the actual act of renaming the folder so the world can see it, makes all the links to my photos within the content fail. There's got to be a better way?
Example of Page after menu name change:
errors.jpg
Error Example
errors.jpg (106.3 KiB) Viewed 3130 times
The majority of the problem lies in the fact, that as far as I can perceive, there is still no way to add relative paths to things like pictures that may be contained in content. If I'm wrong about this I apologize, but all my recent attempts with the newer version resulted in failed links. I brought the relative path issue up earlier, and I'm sure someday it will be implemented, but for me not having it sooner rather than later will means hundreds of paths to change. In the past with X2 and earlier X3, I've downloaded the appropriate files (like .xml) and made global changes locally and then re-uploaded all those changes. Not sure this will be possible in the revised X3, but hope so, because I have lots of links to fix. I bring all this up now, because it took me a tremendous amount of hours to get my site from X2 to X3 and now with X3 changing, I fear I may be wasting many more hours to a losing end result.

I'm not complaining about anything here, I'm just concerned and want X3's development to grow in a positive way for everyone. I want badly to stick with X3. I love the freedom you have given us to develop what WE want our site to look like. My site is extremely folder heavy, I know that's a burden on the X3 software, but that is what I want. I use huge amounts of content (html), but that's what I'm looking for. I love that you listen to your clients and develop for all their needs. If there's any way I could help brain storm on this, let me know. If you need my site for test anything (like you have in the past), your welcome to do so. I am windows based and I know that has helped you on other issues.

Thanks for listening Karl, sorry so winded and as everyone always says "Keep up the good work" things are looking better each version.
Joe

Some other tiny questions/comments
1. Clicking on a popped-up photo now zooms again. Can this revert back to previous function where it advanced to next photos (no double zoom). I don't want my viewers to have to chase little arrows on the sides unless they desire that.
2. I know you may not have any future for the search form you create for the original X3, but I love it. I would would love to see the development of it at some point advance. This of course could be a low priority item. One major revamp it needs is that it currently brings up pages that are hidden from public view. It needs to NOT reveal links to pages unless they have a number prefix delegating them as for public viewing.
3. Early testings with the the new popup box are positive. Love what I see. It does have a small issue though. It pushes the popup box to the top of the page sometimes, into the close popup area. This means if there is something on the popup page that is clickable, it is impossible to click it, because it will close the popup window. For example, if you go to your YouTube video on the samples popup page. It brings up the you tube video nicely, but there is no way to click on the links (like sharing) at the top of the video, without just closing the popup. Hopefully you can just shift the popup down a little to avoid the clicking collision.
 
User avatar
mjau-mjau
X3 Wizard
Posts: 13998
Joined: 30 Sep 2006, 03:37

Re: Some Concerns

09 Nov 2015, 01:43

Before anything else, did you try using the dynamic {{path}} parameter in your content? It automatically converts to the physical folder path of the current folder, regardless of how you rename it.
Code
{{path}}filename.jpg
The above will convert to the true path of the folder, for example:
Code
 /content/1.category/3.folder/filename.jpg
Even when you change the names of the folders, the {{path}} var will refresh.

As far as I can read, the entire issue in your post is solved by the above.

Furthermore, although I understand your concern, I must emphasize several reasons why this cannot be as logical as you perhaps are hoping:
  • If a page url was identical to the true path, that would mean we cannot use the /content/ folder to contain the content. Furthermore, this is not really possible because a true folder path would actually point to the folder, and prevent the X3 application from creating a page from a "route" (virtual pretty page url). Of course, even if it was like this, renaming folders could still lead to broken images. Additionally, it is pretty common sense to abstract the physical path, so that visitors can't sniff the physical path which could lead to unwanted behavior.
  • Url !== Path. Unfortunately, as noted above, the url cannot be the same as the path for several reasons. The Url is a practical abstraction of the true file path. In context of a CMS, without using special vars (eg {{path}}), relative paths from a CMS content editor simply do not apply.
  • Relative link? The fix noted earlier does this, and I believe you already understand why an embedded image cannot simply be noted as "image.jpg". The frontend page itself simply doesnt know the physical file path of itself (apart from using the dynamic {{path}} var), which simply is different from the URL. Therefore, you simply cannot do src=filename.jpg for a relative path, although that of course would be a dream-scenario in a world of unicorns and rainbows.
  • There is no other CMS (even Wordpress) that handles this more gloriously. You cannot link to an image like "filename.jpg", simply because the URL is NOT the path.
  • Naturally, some CMS (especially DB-based ones) may have better handling of this, but it is still through a layer of abstraction ... or simply from the fact that page-linked images are stored in a separate folder that never changes name. The physical link still needs to be maintained.
  • Finally, I would like to make some notes about the custom page content section, which this topic is entirely about. The content section is a free-form section where you can add anything you like, although the X3 applications ability to apply magic here is limited. In fact, X3's main concept is creating pages, adding galleries- and albums, and being able to add basic text content. The content-editor is not at core to X3's capabilities for displaying images or creating custom embedded galleries (for reasons given above, and many more).
./photo.jpg to refer to a current folders photos.
This isn't possible in X3 or any CMS. The ./ notation is a link relative to URL, and Url's will not be the physical folder path. It seems perhaps you have come from a background of editing in a basic html-app like dreamweaver, where you can simply link to an image from the current path? We could perhaps build X3 so it dynamically replaces "./" (perhaps not a bad option), but ultimately of course, it is not using the "./" path, because that doesn't work.
although I personally believe the "industry standard" relative links format give the most power and freedom, especially the double dots "../" (parent) which allows climbing the directory tree.
The same as above, it will link to a virtual path that doesn't exist physically. Relative links simply won't work, because the image paths are not the same as Url's no matter how you twist and turn it. You can use relative links for actual links (<a href="" etc).
The majority of the problem lies in the fact, that as far as I can perceive, there is still no way to add relative paths to things like pictures that may be contained in content.
Apart from using the {{path}} var, that is correct. If we could use relative links, that would be awesome, but that is not possible from a modern CMS app where Url's are routed virtual abstractions of the physical file path (for reasons given in the list, and more). This is only possible if you are building a website with custom html and physical folders, which needless to say, is tedious.
I'm not complaining about anything here, I'm just concerned and want X3's development to grow in a positive way for everyone. I want badly to stick with X3. I love the freedom you have given us to develop what WE want our site to look like. My site is extremely folder heavy, I know that's a burden on the X3 software, but that is what I want. I use huge amounts of content (html), but that's what I'm looking for. I love that you listen to your clients and develop for all their needs. If there's any way I could help brain storm on this, let me know. If you need my site for test anything (like you have in the past), your welcome to do so. I am windows based and I know that has helped you on other issues.
We are open to ways for improving the content editor. Perhaps there will be more shortcodes in the future, and maybe a toolbar item to embed images from the current folder. If you are overly concerned about the direction X3 is taking because of a custom content-editor, which is limited in what we are able to offer and which is not core to X3's features, then I might suggest that your expectations of this aspect of the CMS may be too demanding.
1. Clicking on a popped-up photo now zooms again. Can this revert back to previous function where it advanced to next photos (no double zoom). I don't want my viewers to have to chase little arrows on the sides unless they desire that.
Will add as an option in settings soon.
2. I know you may not have any future for the search form you create for the original X3, but I love it. I would would love to see the development of it at some point advance. This of course could be a low priority item. One major revamp it needs is that it currently brings up pages that are hidden from public view. It needs to NOT reveal links to pages unless they have a number prefix delegating them as for public viewing.
Will consider it for the future. Unfortunately, "search" is a big "can-o-worms" as they say, especially for a file-based CMS.
3. Early testings with the the new popup box are positive. Love what I see. It does have a small issue though. It pushes the popup box to the top of the page sometimes, into the close popup area. This means if there is something on the popup page that is clickable, it is impossible to click it, because it will close the popup window. For example, if you go to your YouTube video on the samples popup page. It brings up the you tube video nicely, but there is no way to click on the links (like sharing) at the top of the video, without just closing the popup. Hopefully you can just shift the popup down a little to avoid the clicking collision.
The new popup, where a lot of the credit must go to a great 3rd party dev, is highly complicated. It has so many events that track swipe, click, touch, which prevent many features in the "custom" popup. Currently, it is therefore advised to use for only images ... If using for any custom content, there are a few limitations, but hopefully we can look into it at some point ...
 
User avatar
sprocket
Experienced
Topic Author
Posts: 98
Joined: 18 Dec 2008, 19:40

Re: Some Concerns

09 Nov 2015, 18:04

Thanks Karl, I didn't know the dynamic {{path}} parameter existed. That should solve my issues as far as I can see right now. I'll give it some testing. BTW, is there going to be some instruction soon on how to update our existing X3 sites to the newer X3?
Joe
 
User avatar
mjau-mjau
X3 Wizard
Posts: 13998
Joined: 30 Sep 2006, 03:37

Re: Some Concerns

10 Nov 2015, 00:23

sprocket wrote:BTW, is there going to be some instruction soon on how to update our existing X3 sites to the newer X3?
Joe
Yes. There already exists a convert.php script, but I will make an official post about it later this week and I recommend waiting until then.
 
User avatar
sprocket
Experienced
Topic Author
Posts: 98
Joined: 18 Dec 2008, 19:40

Re: Some Concerns

02 Dec 2015, 19:06

Karl, do you think it would be possible for you to create a place where users could assign variables paths of their own? The {{path}} solved ALMOST all my path problems, but having a path variable name I could control myself would eliminate ALL my path issues and add some real advanced control. This would allow me to change roots paths within all pages with one edit. Your {{path}} variable points to the current page, but maybe a place where we could do something like:
Code
{{myblog}}='/x3/content/travels/'
{{featuregallery}}='/x3/content/landscape/'
{{GPS}}='/GPXViewer/'
So we could do things like like this in the content:
Code
... Latest photos seen <a href='{{featuregallery}}'>HERE</a> for your viewing pleasure ...
... Especially check out this <href='{{featuregallery}}_bestpic.jpg' data-popup>Lion photo</a>
similar to using the {{path}}, but user defined?
This would really end all my issues and add some interesting possibilities, along with making content link edits seamless.
Thanks for listening
Joe
 
User avatar
mjau-mjau
X3 Wizard
Posts: 13998
Joined: 30 Sep 2006, 03:37

Re: Some Concerns

03 Dec 2015, 00:16

It's a good idea ...

First I was thinking they are not dynamic variables, but I see the practical advantage of storing some paths/links as vars.

This will however have to wait a bit as we need a month or two now to focus on launch of X3, including a new website and documentation. Besides, this is part of the aspect of improving content editing in many areas, which we want to spend some time with soon.