diogo

Happy Holidays to all of you! I'm visiting Berlin for the first time and I'm loving it. My first website with PW was launched yesterday but I will post it here only when I go back home. I'm without internet, and I wouldn't be able to get your feedback if I would do it now. Thanks for the card Ryan, you have a lovely family!

Ah... of course... This was the code that was breaking it: $(".menu td:first-child").text(function(n){ var content = $(this).text(); var dots = "..."; var both = content + dots; return both; }); EDIT: Ok, I manage a workaround, although it will mean a bit more complexity to the editor. | _something here_ | something here | | _something here_ | something here | | _a line break here_ | something here | $(".menu td em").append('...'); td em { font-style:normal }

It's working now, even without raw tags. I redid everything and don't really know what fixed it. I will report if there is something else.

I'm, using the textile module on a site I'm building and there seems to be a bug when building tables. When I do this: | something here | something here | | something here | something here | | a line break here | something here | the line doesn't break. I looked for some reason, And apparently, people that had this problem solved it by adding a raw <br> (bah!), but even this doesn't work with me... here everything works fine http://textile.thresholdstate.com/

Makes sense from that point of view. The speed is better now Soma. Nice!

Hey! the pink on top is great, i can't imagine pw without it anymore

Nice works, by the way

I didn't see it overlapping on my install, only on Soma's screenshot. I saw it now, and I also like it. edit: it's definitely more elegant

Ui, not easy to solve... Maybe a green button only on the Pages page, like this one in Modules... but I'm not sure... edit: the one that is now, is a more elegant solution for sure

a : is missing

That's why it's so funny that you named the CMS Dictator before

There are two things that are bothering me. I think the + button would work better next to the title of the block instead of the bottom, and the animations feel to slow, I would say they aren't even necessary... But this is getting greater and greater. Much better than a simple pdf for sure edit: I meant only the animations for the advanced items toggle. The animations on each individual items are ok

great

I understand that, but since the content is scrollable, to me it feels more right to have the menu always there. Not very important though, the cheatsheet works great as it is

If it says explicitly that it does the same thing, can't be confusing. I would say it's good to show that people can use both. Soma, how about making the menu position:fixed? I think it might make it more comfortable. edit: Although you would have to deconstruct all the table for this

I'm also undecided. For one side, would be nice to have it all translated, feels a bit strange to have some parts in one language and other parts in another. For the other side, I think that it's very unlikely that someone who doesn't understand english could build a site in pw... no documentation, no forums... hm... so, yep, makes sense to target the translations only for editors... Maybe would be nice to have a hierarchy in files, so translators can choose how far they want to go. But this makes sense only if it doesn't mean work for Ryan alone

Finished the first draft of pt-pt. I still want to check again if everything is ok. http://modules.processwire.com/modules/portuguese/

Glad I could help ;D

they will for sure, although not exactly the same effect. nice I was thinking that it might be more difficult then I was imagining... yaaaay!!

I didn't! Thanks Soma, these are very useful and I had never look at them. Ryan, couldn't they be used on the default site so people would be immediately aware of them?

I also think it would be useful to use the same field type with different labels, and even having it repeated on the same template with different names. On my project, I had way to many field types for the simple task I was doing. I had something like these field types: plate1 plate2 plate3 plate4 plate5 price1 price2 price3 price4 price5 when the ideal would be having only "plate" and "price" as field types, and put them on template as many time as I wanted, naming them only there. I also had to repeat the process of choosing "type", "text formatter", "input size" and "max length" for each one of them. Would be very useful to have the option of duplicating a field, just like there is the "duplicate fields used by another template" when creating a new template. Or maybe there is already a better way of doing this and I was having unnecessary work. Is there?

I'm feeling the need to have the template forms more organized to make them more readable for editors. The problem is that, it quite difficult to group pieces of information together inside the same form. I was thinking of two possible solutions for this. One would be simply dividing the form in columns, so you could for instance, on a restaurant menu, put the name of the plates on one column, and their prices on the other. The other would be dividing the fields into groups inside each page. I know we could make a page for each group instead, but in some situations I think it just makes it more complicated for the client. Those groups could be there only visually for the form, or they could even be called from the API, why not? $page->group1 could return an array of the fields inside that group. Just a very rough idea, and a very rough draft on the attachment...

hm, I think Pete is right, "Content" would fit very well on the menu

Well organized and easy to navigate! Well done

I would also prefer it in the top right, next to the navigation