Soma

did you put the meta tag in the templates-admin/default.php too?

..for sure it must be this, I for some reason just assumed he must know it and have checked already... stipud me Yeah, good one apeisa. Maybe good idea to put in admin templates.

// we don't even want to go there if($.browser.msie && $.browser.version < 8) { $("#content .container").html("<h2>ProcessWire does not support IE7 and below at this time. Please try again with a newer browser.</h2>").show(); } Not sure, it should be pretty solid, although I heard it's not completely rock-solid-bullet-proof in jquery using this browser sniffing, but there's a more solid around. Would have to search for it again in case.

PW supports IE8 and above, not sure why you get that in IE8. I had to test and fix some things in IE8 already as my clients are on IE8 many times. They didn't had problems like this so far. Can you check what your user agent is set to in your IE8?

Hey visulin thanks for your input, but that's basicly the idea what we (I) want to do. A setting in the inputfield where you could enter the path to a css outside /wire/ folder, basicly anywhere you want in your root or site folder. You could set all tinymce fields to share the same, or each one a different.

Aaaand I was waiting for this answer since 2 months as I wrote a lengthy post back then about this issue above in this thread asking how this issue could be solved... Think you must have missed it then

Thanks and welcome to the forum! I think the problem is that the breadcrumb shows the current page. like "Users" at the end, but it shouldn' even show up. It should be like on setup sub pages, it doesn't show "Fields" for example if you're on the "Fields" page.

I think you missed this thread

Hey, almost forgot about it, but only almost. I recently just was thinking about this one, great to hear you're working on it Nico. Unfortunately I got so much up with higher prio, I need to catch up first before I could spend more time on this.

You know the html templates in TinyMCE you can setup, to then select from the dialog using the template button? It allows to insert chunks of html i.e. table, divs, just predefined html being inserted ready to fill in your text. It is implemented in my version. You just need to add the "template" button to the config and maybe "tablecontrols"... the html templates config is hardcoded into the config js and the files located in the folder "tinymce-templates". I think it's a nice feature. oh dear, since I already done some fooling around I could give it a try... just think need your assistance... but wait.... The hard thing for me is that I'm still not sure, what and how far this should go. - I think for now we just can implement the css bramus plugin into the distribution, and maybe enable "templates" settings, those can be placed outside core anyway too (I think). Same with the content.css. - If one is in need of another plugin, I could try if it's possible to include it from outside core too. - If one needs even more, I would suggest moving it outside core and go from there and maintain it. So I'm still trying to wrap my mind around (not first and last time I guess). Any more ideas, or thoughts? I also think spending some energy and time to the PW plugins in tinymce, to extend or improve those, would be nice?

Looks nice, like the illustration work also. I can't say that from the website , it looks nice, but first time I visited I didn't go any further than homepage, there was something strange. Now looking again, "advertisement" show just a white page, that must have been the issue before. Also I would recommend checking the image sizes as many are far too big, bigger than ever displayed. That results in a slowness of the site, which makes the experience worse.

Thanks Ryan, Pete it works now. No limit

apeisa, it can be used, i posted code above already... but I use it just for admin related tools, prototyping with bootstraping. It wouldn't be recomended using it in front-end production, because of the things apeisa mentioned.

Awesome Nico! Thanks for sharing. Will for sure check out some time.

I think you can do something along these lines, not sure though about side effects <?php // loads modules, that will add it to the script loading below $this->modules->get("JqueryCore"); $this->modules->get("JqueryFancybox"); ?> <?php foreach($config->styles->unique() as $file) echo "\n\t<link type='text/css' href='$file' rel='stylesheet' />"; ?> <?php foreach($config->scripts->unique() as $file) echo "\n\t<script type='text/javascript' src='$file'></script>"; ?> Of course apeisa and diogo is right, but I just wanted to show it's possible. Edit: while kinda on topic. Ryan, could we have an updated Fancybox? The current in PW "1.2.6" is way outdated. I always struggle to get iframes working. I could need some of the more advanced features, options in the PW admin.

Ryan, I think it's best if you copy it from my repo. If you don't mind. Since you also would need to implement something to allow external content.css. How about templates for tinymce? Also would you also suggest it still being the prefered way to copy it to the site modules folder for extra advanced tweaking? Or would you see it possible to connect some more to be able to put in site folder, like additional plugins, templates? I could imagine having more advanced config possible to for example put in the js config code into a field or the like? What would be the way to go? As you know we already went this far with the topic, and I ended up copying it to site modules folder. Yeah you're right about the core, I just always assume everthing in "wire" is core. Though looking closely it's kinda bundled into the distribution.

Glad you like it. I think there isn't any downsides, at least none I can think of now (im using it in a couple projects now). Only thing I would question is, if we include it in the core, the content.css is also there. But anyway it would be possible to allow having a content.css in the site folder for easy tweaking. As is it something that has nothing to do with PW and just sits on top of it, one could question why it is in the core anyway. Speaking for myself, it's always the first thing I do since a few projects already, move that module to the site folder, so I have full control, without touching the core. But for sure it would be excellent to have a better implementation of it in the core. Can you upload files?

Ok since I still can't upload files here, I just created a repo. https://github.com/s...ldMyTinyMCE-PW2 here's the plugin used http://www.bram.us/p...amus_cssextras/ I forgot I updated it already with the version Ryan put in PW. There's a content.css which I used for a project, so feel free to change it to your needs. Basicly you can use it to style the look of what you have in the body in the RT to look like on the frontend (fonts, colors, styles), just put them carefully into your content.css. Only html selectors like a.myclass, td.mytdclass get's parsed, so you can use ".myclass" to style without getting added to the select. And only if an "a" is selected the dropdown gets acitvated and show's the class. Oh and you can also do the same with #ids. There's also a template setup included, in the "tinymce-templates" folder are the html files you can select using the "template" button (just need to add it to the config, as it's not in by default). They are then also added to the config in the js with path and name/description.

I spent a lot of time looking for a solution to styles select in tinyMCE. I ended up using bramus css extras, as it allows for inherit and dom element dependent styles. So from infos, he states that it fixes problems with the tinyMCE default styles select only allowing anchor styles and some other weird behaviors. So his plugin enables to do things like li::ul[ yourclass ], so if you have selected a li it will put the class on the parent ul. Also it only shows styles that are allowed for the current selected dom element. It also can be set up to so it parses the .css file automaticly. When I started playing around with it in PW I ended up copying the tinyMCE inputfield into my site folder and rename it. So I could easily setup whatever I want without touching the core. Since then I use it this way. It was still using the older version before Ryan updated it, so I'm not sure if it is any different now, but I doubt. I can if you want attach my modified version, so you could try and go from there. I'll just have to clean it a bit. BTW I also recognized a strange behavior with the configuration "theme_advanced_buttonsX", I had to add 'theme_advanced_buttons3 :""' to get a 2cond menu bar working. I wasn't working straight away. Just forgot completely about it.

Glad I could help. TO my understanding, it wasn't working cause you check for "hover" event in the live method, and then e.type will never return "mouseenter". It's unlike the .hover method which binds mouseenter,mouseleave. Dunno why exactly it is like this, but I guess it should work all well. I haven't tried but maybe it would require to write .live("mouseenter mouseleave", function ... ) { if (e.type=="mouseenter") .. to make it work with those events.

I've checked this one out on my local PW2.2 isntall. I get the same problem with the hover not working. I fixed that one by changing the InputfieldCropImage.js a little. The live hover event wasn't working. I changed it from "mouseenter" to "mouseover", and it's working now. I'm not sure about github. I have the repo local and commited the fix just now, but I don't know if it gets commited or apeisa needs to pull the commit first... So heres the code for those interested: $(document).ready(function() { $("a.crop").live("hover", function(e) { if( e.type === 'mouseover') { url = $(this).data('thumburl') + "?timestamp=" + new Date().getTime(); $(this).append("<img style='position: absolute; z-index: 999;' src="+url+" />"); } else { $(this).find("img").remove(); } }); $(".InputfieldCropImage .InputfieldFileList").live('AjaxUploadDone', function() { console.log("it should"); $("a.InputfieldFileLink", $(this)).fancybox(); }); /* Modal disabled, cropping huge images is very difficult with modals $("a.crop").live("click", function() { var url = $(this).attr('href'); var windowHeight = $(window).height() - 120; var windowWidth = $(window).width() - 120; $iframe = $('<iframe id="pwimage_iframe" width="100%" frameborder="0" src="'+url+'"></iframe>'); $iframe.parent().css('position', 'fixed').end().dialog({ title: "Crop Image", height: windowHeight, width: windowWidth, position: [60, 60], modal: true, overlay: { opacity: 0.7, background: "black" } }).width(windowWidth).height(windowHeight); return false; }); */ });

@apeisa, yeah that sounds like a good approach. I like the idea. And the shop cart module is already there, just needs some tweaking and maybe some more options. I think a plan would be helpful to list what we got and how it could work out, in other words a project plan? Or really look closer into what is needed as a base to help build a shop (cart module?) and build up different modules around it that add functionality independent, so one could pick what he likes and add to the project with a module. So with a PW install everybody has access, we could build up some default shop to try it out and everyone can contribute, export a profil (fork, github?) and try it out on local server if wanted. @jbroussia, you're right it's strange, something I didn't recognized until now. Seems it is something done on domain name server routing that ignores it. Or could be even on browser level. Not sure.

Current version you can see the dev site here : http://dev.bag-shop.ch. Here you can see a product with color variations http://dev.bag-shop.ch./de/kollektion/taschen/paula/ . I will provide a profil export once I got the time maybe next week. I think the "problem" regarding product options and variation is not a simple one, once you need to do colors, different sizes with own prices, and even more options per product. But certainly not impossible, though it could get tricky. Maybe just not as nice to handle those in the admin, as it may could be with custom fields, repeatable fields, or even custom page types. But since PW is still evolving in this area, I think it may best to wait a little to have more options available. For instance the repeatable fields could then be used for variations. But my best guess would be that the way it will be implemented is by using invisible subpages anyway, so it's hard to tell right now how this could be used. I'm also very unsure about how far such a PW shop module should go and provide all the necessary functions and options a full blown shop system should have. There's certainly a lot of things that come together. For example things like stocks, multilanguage, reduced prices, shipping costs depending on total prices etc. customer management and so on... I'm also not very experience in full blown shop, as I really just coded 2 very simple shops for customers before, that didn't needed any of those features. Also the shop module in our CMS was only able with a little trick to create variations with different prices per product, but provides an interface and API for them and its much like repeatable elements. I'm not sure how more complex variation could be handled but certainly there's a point where it might needs some additional coding in the core or shop module. I don't know any of the avaiable ecommerce software out there but I also haven't heard much good from some of them, so I guess it also hard to go with that route and chose among the ones out there anyway. I love to have a flexible CMS/CMF that allows easy coding and freedom, so many of the features can be done in some way or another. Maybe we should look for what is the most needed features for simple shop setups, and allow simple extending by using PW style 100%. I mean only provide the essential core functions a shop needs. So an more experiences site builder can easily setup something. But if someone wants to go for a complete out of the box shop module, I certainly don't want to stop them. Certainly something for people that don't have the ability to do advanced coding.

I don't understand exactly how it could get messy, but maybe you're right. No I didn't encounter any errors, just added as function to get total items in cart. And I removed all of the cart, checkout form, add to cart markup genrating functions, as I don't really need them. And I added some more fields to the installer for the order template. Also as mentioned I added simple variation price check in the add to cart functions, was pretty easy and I think you've done a great job. I agree there could be some sort of markuup generation tools in there, but then it should be configurable or still one still being able to completely code their own in the templates. It is the case for another CMS we use at work that has a great sho module already built in. And it has no markup generation functions at all only helpers and method for adding, updating, removing from cart and saving the orders for use in the orders management. Edit: Oh and I thought the logic you got together with the markup genrating function, to add and render the checkout process was very hard to track and understand with all the post/get vars starting from the entry point in the renderCheckout function. That's what I simplyfied a lot by having some logic of it in the template. That way I'm not bound to it and can make the process of the ckeckout the way I need it.

I'm currently setting up a simple shop, using the module apeisa started. It had to go quickly, so I had no time to wait for further progression on this. But I wanted to share my experience these days with you guys. It is really a simple shop with products that have color variations. The payment method will be credit cards using a external service (little like paypal). Since they have already an order management, it doesn't even need the orders management apeisa started implementing, but it will be good to additionally save orders in PW. As for the variations I created sub pages on the product, so I changed the cart functions to look for if the variation has a price, else it takes the price from the parent. The cart saving feature in the custom module table is great, but I doesn't need address, so only session id and the serialized cart will suffice. And the saving order using a template with the needed fields isn't touched but in my case it does need a lot more fields than apeisa started with. So the gender, address, city, country can be entered. As for the module to keep it flexible, I think it is best to leave out all hard coded "html" and "forms" generation of the module code. So I have the sc-checkout template all the logic of the process. So I'm able to code the shopping cart the way I need it, and just request the items array using the public module function. I didn't even used the renderAddToCart like function to generate the "add to cart" form fo a product, as it is simple to code a form to my needs and just have the product id in there, and the action url to the cart page. So only really function to handle the cart are necessary. I'll be glad to help with this module, and I'll share the project once it's done next week.