Re: [TYPO3-english] TS condition for browser and FE users gives weird error
Just to close this topic. I figured it out. The problem is the additional FCE container. When I set the browser conditions for the individual elements then everything work as expected. So just avoid the extra layer of an FCE container and it will work. /Morten ___ TYPO3-english mailing list TYPO3-english@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-english
Re: [TYPO3-english] CoolURI setup for html5videoplayer
Hi Jan I completely missed that you answered to this thread. Sorry. Thanks for the help. I have managed to shorten the URL to: http://domain.com/tutorials/63f8283492d2ab2eddd911c79caa05ec/detail/video-title/ 2735279785110c9c7fde56b8e9f3f77f/ what's that? I am wondering about that too and will ask Tim Lochmueller about that. tx_html5videoplayer_pivideoplayer[action]=detail Uripart to include detail into the URL, or predefinedpart to remove I have added this to my uriparts setup and it gives me detail in the URL just as you said. part parametertx_html5videoplayer_pivideoplayer[action]/parameter /part But can I do a really simple rewrite so I get e.g. video instead of detail? So the last part of the URL becomes /video/video-title/. It is properly dead simple. Also the tutorial by Andreas Becker seems to be down: http://docs.google.com/View?docid=dd33gg45_3f8j96p Thanks Morten ___ TYPO3-english mailing list TYPO3-english@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-english
[TYPO3-english] Uploading problems TER - Server 500 errors
Anyone else having problems uploading extensions? Stephen ___ TYPO3-english mailing list TYPO3-english@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-english
Re: [TYPO3-english] TYPO3 CMS 6.0 activate sorting in page module?
Am 09.12.2012 11:50, schrieb Jigal van Hemert: Hi, On 8-12-2012 11:57, JoH asenau wrote: Exactly: Drag drop is nice when you want to move elements between columns or for longer distances. In any other case a simple click on a sorting icon is much faster and therefor the better choice regarding usability and performance. Reloading the entire page is faster? Besides, dragging can be done with the entire title bar and you don't have to look at a small triangle to see which button you should use. Most people prefer dragdrop over buttons. Also if you have to move it more than one position you would need to click multiple times, you would have to wait for multiple page reloads. Talking about speed... Did you notice the long distance? - Moving elements up or down will be faster with a click, moving them for more than one or two steps will be faster with DD. On the one hand important buttons have been removed (sorting, add CE on top of the module etc.) Add a CE on the top position of a column? That button is there. It's only visible on mouseover to reduce the amount of information. Of course it is there, but I meant the button on top of the page module (not just one of its columns). It has been used to first select the element type with the new CE wizard and then select the column to put it in. And with Grid Elements it is used to trigger the drag in wizard. on the other hand buttons have been moved to places where they are just wasting space (add CE after another CE), which leads to a signifcant change of the overall height of the page module forcing the user to scroll down. That button was there in TemplaVoilà and people liked it. It is far more logical than a button in the title bar of a CE to add a new element below. The new CE button is now in the location where the new element will be placed. So it is wasting a space that is currently not in use. I agree that a position on top of the element is suboptimal as well, but actually it would have been enough to keep it at the bottom of the element but still inside it. Not reloading the page module with drag drop IMHO is questionable as well, since you won't notice changes made by other editors early enough. If you open a page for editing there is a message that another editor has started modifying that page. That should trigger you into asking the other editor if he's still busy. First of all, you can't do that when working on different content elements, since you will only get that notice, when editing the page itself. And of course this only works for small teams but not in enterprise situations with lots of editors working in different locations. Reloading the page after dragdrop is something that nobody does, because it causes an interruption in working on that page. Reloading currently is the only way to get all the necessary information about the current state of all elements on that page. The longer you stay while this status gets changed by other editors, the more you will possibly break with your Drag Drop actions. Especially when you enable copies with drag drop you would have to create ALL the classes, JS and HTML code for the newly created element at the client side and modify the rest of the elements accordingly, which is.much more complicated than a simple reload. (Maybe this is the reason, why drag drop currently only works while moving elements?) Maybe current dragdrop is simply a replacement for the sorting buttons? Other implementations of dragdrop for TYPO3 that I've seen don't have a dragdrop-copy action. It's there in the page tree so you could expect it for content elements as well. Besides, it only requires rendering the newly created element. No need to modify the rest of the elements accordingly. You definitely have to modify the other elements, since they need to know about i.e. their new position and other things in relation to the copied element, otherwise the page module JS won't work properly anymore. Currently our plan in the Grid Elements team is, to reenable the old behaviour with Grid Elements and provide a slightly modified page module with less waste of space, more functionality, active sorting buttons, completely working drag drop actions and drag in of new content elements. After all we should take care of the needs of the users, which seems to be slightly different to the perception of these needs within the design team. Maybe we can convince the core team to go this way together with us. :-) You know very well that the core team tries to make/keep the core as light weight as possible and have extra functionality in extensions from TER. Yes, there are a number of system extensions which should also be moved out of the core and work on that is slowly done; simulatestatic was first moved from the core code into a system extension and now finally moved to TER. If you want 'speaking URLs' you now have to install an extension like RealURL, CoolURI,
Re: [TYPO3-english] IE9: Upgrade TYPO3 4.7.4 - 4.7.7 makes BE crash when saving through RTE
Hi Bert, I just updated several sites from 4.7.4 - 4.7.7 and got feedback from clients that in IE9 only (!) when saving through RTE (hmtlarea latest version), the Backend and IE crashes completely. When logging back in, data are saved but got no idea why this upgrade makes IE crash. Please test this change: https://review.typo3.org/#/c/17035/ Regards, Stanislas ___ TYPO3-english mailing list TYPO3-english@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-english
Re: [TYPO3-english] additional fileadmin folder
Hi Philipp, problem solved; /path/to/typo3/ was only the full path in the chroot environment. Typo3 is not satisfied with this and wants the real real path; /path/to/chroot/path/to/typo3/. Now it's working :) regards, Georg Am 10.12.2012 01:51, schrieb Philipp Gampe: Hi Georg, Georg Schönweger wrote: Real Path to file /path/to/typo3/downloads/long_file_name.txt Path created by linkwizard: ile_name.txt _blank Correct Typo3 link would of course be: downloads/long_file_name.txt Any ideas? I saw that somewhere before. I guess this is a bug. Best regards ___ TYPO3-english mailing list TYPO3-english@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-english
Re: [TYPO3-english] jb_gd_resize does not resize pop-up image
It seems that I had missed manually to reduce the size of some of the pictures uploaded. It seems that pictures uploaded larger than the width and height set in imageLinkWrap for the popup window will result in popup window only showing parts of the picture. In other words, the uploaded picture has to be smaller than the popup window max. size set in imageLinkWrap in order for the resizing to function. In other words, problem solved and jb_gd_resize functions excellent. Regards, Gunnar Jonsson Jan Bednarik skrev i nyhetsmeldingen: mailman.1.1324139644.23128.typo3-engl...@lists.typo3.org ... Hi, I thought that popup image is shown in its original size, usually. So, what is your scenario? You have an image that is bigger than maximum size? Jan Dne 16.12.2011 21:36, lists.typo3.org napsal(a): I am using the extension jb_gd_resize since imagemagick is not available at my webhost. It works fine with ordinary images in image text content elements. However, the pop-up images with click-enlarge property is not resized. The pop-up image is only partly shown since it is not resized to fit in the pop-up window. Anyone who knows what to do in order to force jb_gd_resize to resize the pop-up image? Regards, Gunnar Jonsson ___ TYPO3-english mailing list TYPO3-english@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-english
Re: [TYPO3-english] CoolURI setup for html5videoplayer
Hi, 2735279785110c9c7fde56b8e9f3f77f/ what's that? I am wondering about that too and will ask Tim Lochmueller about that. Maybe cHash? But can I do a really simple rewrite so I get e.g. video instead of detail? So the last part of the URL becomes /video/video-title/. You can use valuemap to do it. Regards Jan ___ TYPO3-english mailing list TYPO3-english@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-english
