You are not logged in.
Hello There.
Big thanks for such a great system so far and I can't wait to see where this is heading. I love it so far, even though I've had a rough time getting to understand the concept behind it. But once you do, it's sweet ?
I've encountered a few glitches and bugs (worst one making it work on a server^^). But honestly. There was one bug that I think is a little annoying as it forces you to use phpmyadmin to fix it after content-change.
I'm using the demo data set of BigTree. When you are modifying the trees, (elements of the class trees), it keeps erasing the route (from "-2" to "") which leads to the item not being able to be called through the website. Fix is easy, Reentering a route in phpmyadmin.
The module-backend page for trees includes all possible information (title, content, galleries, link, attribution, etc.) But it doesn't give the option to change the route while editing the content itself.
Am I missing just something here?
Offline
You're right, it looks like the demo form for Trees doesn't have its route field setup properly.
You can fix this by editing the form and clicking the tools icon next to the Generated Route field. There's a dropdown in the Field Options that is for Source Field -- it should be set to "title". That will fix the route generation to stop making it disappear on save.
Offline
You can fix this by editing the form and clicking the tools icon next to the Generated Route field. There's a dropdown in the Field Options that is for Source Field -- it should be set to "title". That will fix the route generation to stop making it disappear on save.
Amazing. That easy. Still have to wrap my head around the system, but I just love it.
I do have another weird issue. it doesn't treat Ä Ö Ü and such properly, it breaks it somehow Any reason why?
Last edited by florianuhlemann (June 26, 2015 6:14pm)
Offline
Can you give me an example of how it breaks (is it displayed wrong on the front end website or in the admin)? The database should be in UTF-8 encoding so it should support a very large character set.
Offline
The database should be in UTF-8 encoding so it should support a very large character set.
Database and tables are set to utf8-general-ci.
I copied the same info into header, nav link and content. The mySQL entry is now "schl\u00f6\u00dfer" (page_header) but it's "schlößer" for page content. (which works)
Offline
I'll try to look into this some more -- it looks like the fields that are running through htmlspecialchars are somehow getting encoded incorrectly.
Offline
it looks like the fields that are running through htmlspecialchars are somehow getting encoded incorrectly
Thanks a lot. I appreciate the time you spend helping out.
Something along those lines was my guess too. And the weirdest part is, that it's not happened before (on my first installs, i.e. with debian+lighttpd+normal routing). Since I've wanted to use the advanced routing techniques, I had to switch over to ubuntu 14.04LTS + apache2 and now I encountered that problem.
Offline
Database and tables are set to utf8-general-ci.
I copied the same info into header, nav link and content. The mySQL entry is now "schl\u00f6\u00dfer" (page_header) but it's "schlößer" for page content. (which works)
Problem found. Apache2 didn't have "UTF8" set as standard charset. fixed it in /etc/apache2/conf-enabled/charset.conf by uncommenting AddDefaultCharset UTF-8.
Offline
Excellent! Glad you found the problem
Offline
Somehow, a different, yet related, issue just came up today. Can't figure out why. Any idea?
What happens: I edit the content of a page and save, it creates the <p> around each paragraph, yet when I call the site, it again displays the TEXT <p> instead of using its html-code-property to display the site as you want it.
I enter:
This is a sample text.
It has two paragraphs.
What is saved in the MySQL table:
<p>This is a sample text.</p><p>It has two paragraphs.</p>
What the Website shows:
<p>This is a sample text.</p><p>It has two paragraphs.</p>
Error causing it, I guess, would be the php-function "htmlspecialchars()" and "htmlentities()". Or is my php just messed up? I'm using php as a module in apache2. Better recommendation?
Last edited by florianuhlemann (June 28, 2015 6:37am)
Offline
By default, almost all of the different field types will automatically encode data via htmlspecialchars. The main exception to this is the "HTML Area" field type which does not. If you're using a simple "Text" field or a "Text Area" field and want to use HTML tags you will need to decode it via PHP's htmlspecialchars_decode function when drawing it.
In cases where we frequently want to provide users a text area to drop HTML code into we create a custom field type with a name like "Raw Text Area" that is just a copy of the "Text Area" field type but does not do the htmlspecialchars encoding in its process file. If you want to learn more about custom field types, check out this area (but feel free to ask anything if you're still confused):
https://www.bigtreecms.org/docs/dev-gui … eld-types/
Offline
Maybe I didn't make my point quite clear. Useful information, thanks, but I didn't experience any behavior like that before and I'm pretty sure it shouldn't be like that.
Or maybe not?
Anyways, I found out that some of my page_content fields were set to Text Area instead of HTML. So I've changed this now and I shouldn't experience any issues.
The problem I saw that I didn't enter the <p> at all, it appeared there by itself (though from the WYSIWYG editor) and they suddenly appeared in the website again. Should be fixed now though as I was most likely using the wrong field type (and with previous setups I had a wrong/nonworking htmlspecialchars() throughout the site^^)
Offline