LostKobrakai

If the database entries are looking like they should be, than it should not be an issue of CKEditor. One thought: Could you copy the html from the database into a texteditor and see if there are any invisible chars, that should not be there? Another way to check for this would be rewriting the html part from scratch in the backend by using a simple textarea (temp. not using the ckeditor to be sure). If the error persists it should be something which happens on calling the field and not an error in saving it.

About your two questions. I think that's all right there. Just note for potential users how this is supposed to work. E.g. it won't work for users not using localised urls (not sure if i would serve an 404 error there in the first place). Also it won't work for a language named "german", which will have a localised url like this www.example.com/de/… or this www.example.de/… .

I've used mustache solely for my latest project and I've never really used any other templating language. I'm also trying to not be biased about different engines, but to point out my view of how to most efficiently "separate concerns", which is the goal of avoiding spaghetti code. To me this means that the designer should be able to work as independent from backend implementations as possible. Likewise it should be the other way around. If your workflow does not provide predefined datasets you can still go the route of letting the designer use default content from a json file and afterwards the backend guy just needs to couple his output to the variables the designer used. Edit: If you want to use classes and id's for dom targeting the desinger has to know those beforehand, too. So I still don't really see the benefits of using the dom method, besides that placeholder content doesn't have to be rendered into the html before showing is as static mockup.

Did you check the database entries and/or the unformatted values of the textareas?

Your first two statements are not right. The difference in using the dom is that you don't even give the designer the ability to change the place of already implemented content parts (a.k.a. the variables of TE's). To stay with my popular-list example: In both variants the dynamic content is the title and the url of those different posts. Where those are used is, in my eyes, the responsibility of the frontend designer. (I left out the list markup as there's no dynamic content in it.) <a href="{{ url }}">{{ title }}</a> The previous code can be changed to the following without any difficulties or changes in the backend code. <h2>{{ title }}</h2> <a href="{{ url }}">Read more</a> or even: <h2> <a href="{{ url }}">{{ title }}</a> </h2> <a href="{{ url }}">Read more</a> The same change would have caused your example dom code to break, because for the first case there wasn't even an <h2> and the "Read more" text on the link would be replaced for no matter what link there is. That's why the only "scaleable" way to use the dom alone would be using classes to identify elements, as the type of elements could change in the course of development and id's wouldn't let you reuse content parts. I don't want to say it won't work, but I wouldn't want to change the backend dom selectors everytime the markup changes and the classes way of selection is really just some curly braces away from using a templating engine. Another great example would be a change in headline hierarchy. Do you really want to change your backend code if the designer decides to put an additional headline above the posts list and therefore the post titles would be inside an <h3> instead of <h2>. That's some spaghetti code in my eyes. That's true, but at best this is discussed beforehand and not as afterthought, it's still a collaboration on a singular site and not two indepentent projects. To keep the concerns of frontend and backend separated one needs to agree on a fixed baseline, in this case which data are available.

That does not work as the whole wrapping markup is build by InputfieldWrapper::render which does not differentiate by the inputfield that will be rendered in it. The wrapper classes can only be changed for the whole form. But as you're using javascript you can simply go back from the inputfield itself to the wrapping <li>. To change the class for the input itself you'd need to hook before InputfieldSomething::render and use this: $field = $event->object; $field->attr("class" , $field->attr("class") . " myclass");

Which class exactly are you trying to change / add to? Each inputfield is wrapped in a few elements with different classes and each field itself has multiple classes.

For improving the image processing you'll need to contribute to the gd library not processwire. Alternativly you could use imagemagick, which is more powerful than gd.

Both very nicely done. I really like the artistic style of the first one.

According to my look at the core files this is defined in a non-hookable helper function ( renderAdminShortcuts() ) of the admin theme. So I don't think there's currently a way to sort those besides by some javascript.

I had the same thoughts and even had a pull request on github which was supposed to change that. But the sharpening does not really sharpen the image in terms of oversharpeing, it's more to preserve sharp images from getting blurry from being downsized, which is what happens without it.

Jpeg can't handle transparency, which is the most prominent reason for not using it in the first place. Therefore a image conversion to jpeg should at least not be a default.

Are you using a jpeg image? Pngs (and maybe gifs, too) can't have it's quality changed.

You're right and I'm really with you, that this is really a replacement of logic. The author of the linked article is right on that part. It's just that using the dom does have it's own issues, if you look at the whole process and not only the designers'. E.g. your designer does implement a popular posts list. <ul class="list--popular"> <li> <a href="...">My popular post</a> </ul> Then the backend guy implements this with some dom selectors. .list--popular li > a: Change text to title .list--popular li > a: Change href to url .list--popular li: Loop for all posts Now the designer decides that he would like to have a separate link and the title as heading before that. <ul class="list--popular"> <li> <h2>My popular post</h2> <a href="...">Read more</a> </ul> This would make the whole dom selection in the backend code obsolete. The link's text would be overwritten and the headline wouldn't get the title it needs. The only way around this by just using the dom would be classes like I proposed above. Whereas with something like mustache (just ignore the logic parts for a second, just the variable insertion) the designer could have made this change independently from the backend, just move the curly braces with the variable names around. Additionally you could still use all your dom functions to implement things like loops before rendering out the variables. mustache is simply html with some curly braces the dom doesn't care about. Using the dom could very well be useful in places, but not for basic templating, meaning getting dynamic content in the place the designer wants it to have. Edit: This is really kinda the same discussion as for css specifity. Binding stuff in a scaleable way to the dom is difficult. No matter if it's templating logic or styling. Maybe have a look at this: http://csswizardry.com/2014/10/the-specificity-graph/ and the talk, which includes this as well https://www.youtube.com/watch?v=1OKZOV-iLj4.

That's true, but I did mention the designer / developer relationship just on the basis of the article. If one is working alone this might work. But just as it's bad for js/css to bind things directly to dom elements it's likewise bad to do that for any php dom templating. Think about what would happen if the article tag would be replaced with a section tag and suddenly the backend code is busted. That's why one would need to use the same conventions, that do apply to scaleable css as well. Both times you want to target a specific dom element. Bootstrap is not dynamic. It's javascript enhanced, but there's not a line dynamic content. If you're concerned that your designer does not grasp if/else statements and recurring blocks of elements (loops) than you'll have a hard time even if you use the dom templating strategy. Also how would they want to get anything done in javascript if they don't get this.

I'm not really sold on this. What's bugging me the most about the concept is, that the author suggests using classes and id's to target dom nodes and this obviously has to happen if the designer shouldn't be able to break the app just by moving any markup in the template. Let's say we don't use id's because they are inflexible and maybe the designer needs for example a title to be displayed in multiple parts so id's wouldn't work. To also seperate out the concerns of styling and frontend scripts we would need to do something like this: <article> <h2 class="headline js-collapse php-title">Artikelvorlage</h2> <p class="php-text">Lorem ipsum...</p> </article> Of course we would filter out the namespaced classes before rendering, even if the author doesn't talk about this mess of classes... Now I don't see how this is fundamentally better than this, the mentioned mustache language. <article> <h2 class="headline js-collapse">{{ title }}</h2> <p>{{ text }}</p> </article> Nobody forces anyone to use logic in template languages. The part that's difficult for each part is the communication between developer and designer about which data are available under which variable name. Nothing can take that of working together on a single product away. About the authors rant against designers needing the whole dev enviroment on their machines: Using static html means also static content. The greatest benefit of having the dev enviroment is that you can test your design with dynamic data and not only static content. The designers which are sold with only having static content on their disposal it just a matter of having some default data as json and compiling the html via javascript. { "title": "Artikelvorlage", "text": "Lorem ipsum..." } One could even use things like Patternlab, which is there to exactly manage only the designers part of building anything for the web. This does compile all your templates automatically you just need to start a shellscript and you're good to go. That's far from a real dev enviroment. And by now I didn't talk about multiplying markup (listitems) and things like reusing partial templates.

Allowed memory size of 33554432 bytes exhausted This is generally the error for to big images. Error: Exception: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away This seems to be more likely a serious issue. Maybe check back with the hosting company why this happens. Look at the console of the browser development tools when you're on a page which is affected by your issue. It will show you all the errors happening there.

While it's certainly possible it's not as easy as you may think it is. Passwords are stored as hashes in the database. ProcessWire will never store the plain text password. The hashing is dependent on the salt value stored in the config.php. The salt is generated as part of the installation process and therefore your live installation may have another salt value as the dev one. If this is the case it means all the passwords of imported users would be invalid after moving them. What you can do is to copy the whole users database table and copy over the salt value, too. As long as all hashes of user passwords are generated with the same salt value you can exchange users as you wish. But if you have users in both installations, where the passwords where saved with different salt values, you can not move the passwords over from one installation to another. You would need to change/update the passwords by hand in this case. Everything besides the passwords shouldn't be a problem.

This means that jQuery (or any other $ dom searching framework) is not available.

While WireArray objects of ProcessWire are countable they are still not real arrays, so you need to use getArray() on the object to get the array of a WireArray object. Then you can use all the array functions.

I'm on mobile, but robots.txt is the keyword. For your current case I would suggest doing a permanent redirect from the testserver to the production one, so google will at least slowly move over to the real urls.

Any chance to get the error log of the apache server? This would make solving this issue way easier and not like trying to hit a fly in the dark.

For a subdomain it should most likely be a rewritebase of "/" as you seem to need to provide one.

The only thing which really depends on the server configuration is the RewriteBase. This is dependent on how php and the document roots are set up on the server. It does otherwise not matter to processwire in which folder it is or under which domain it's called.

That's the case for the backend which ships with ProcessWire. The frontend is always custom and therefore there are no limitations in browser compatibility, but it depends on what the dev does build for you.