Snippets / Parts --- repeating editable content
|
27 posts
|
Hi all, I am trying to thinking of a way to achieve the following:
Any ideas? Thanks :) PS. Please implement a comment preview for the forum. I just had to retype this after forgetting to add a subject line :( |
|
56 posts
|
In my site's custom layout, I've made use of a few snippets. They're quite handy! :D But, yes, better ACL support throughout Frog would be nice. (Perhaps post-1.0?) I believe that Developer users are able to edit Snippets. So, is there any reason to not make this person a Developer, since they should have access to "core" parts of the site? |
|
27 posts
|
>> So, is there any reason to not make this person a Developer, since they should have access to "core" parts of the site? That's the thing, they shouldn't have access to core parts of the site. It would just be the site owner who wants to update their contact details, for example. But generally, I'm quite happy with the ACL in Frog. More layered privs quickly get messy. |
|
56 posts
|
Hm. One thing which springs to mind is adding a part to the "About" page. Then including that within the appropriate snippet. :D |
|
27 posts
|
How would you access that from the snippet? I only know of Is there a way to target a particular page/subpage? |
|
56 posts
|
Then you can use $contactInfo for manipulation. (e.g. to clean up extraneous markup, if you're using a filter.) Or, you can just forgo assigning it to a variable, I suppose. shrugs |
|
27 posts
|
Thanks dude, that works :) So I thought Sorry, OOP beginner ;P |
|
56 posts
|
Well, if everything is an object, the objects have to find each other, no? ;) Actually, $this has lots of functions that are quite useful. Luckily, most of them are easily found in the source. ;) Post-1.0, I'd like to work with Philippe to write a set of comprehensive Frog documentation. Among other things, this will help clear the mystery of $this, and its power. :D Why post-1.0? Well, I've got my personal projects which also need attention! ;) (And, hopefully, some paid work soon… This is a good thing as, ironically, paid work tends to cause me to spend more time on all my projects… And I've got a list of Frog-related stuff I want to do! :D ) As the time nears, I will likely be soliciting input on what sorts of things people would like documented. I suspect I'll end up with an actual book by the end! :D |
|
27 posts
|
So Docs will be valuable. Not sure if the google code wiki is the place for it though, seems kind of clunky at first glance. |
|
56 posts
|
For this purpose, you can think of $this as "this thing". :) And I wasn't thinking of using the wiki. I was thinking of writing up a complete doc set. So, it would be available as PDF and HTML, at the least. But, I'll create a thread for that project when the time comes. :D |
|
541 posts
|
Wiki is there for the moment, because for now I really focus on development of Frog CMS. and you have right
but if you need to do more then one thing with the about page I recommend you to use a var ie:
note the true in content, this mean inherit, so if there this example will result in a 4 queries to MySQL and with this example:
this will result on a 10 queries to MySQL and here this shorter solution with 4 queries too
ok maybe this doesn't mean nothing for you !!! sorry I'm in my little world now with all those plugins thing |
|
27 posts
|
Thanks for the explanation. After reading this several times I think I understand :) So the true (in this case) allows any page to inherit the 'example' content of '/', if it doesn't have its own 'example' content? |
|
1493 posts
|
This is all impressive! But ... isn't easier just to use the same method as the "Sitemap" for this problem?
Done. No? Obviously there's some advantage to the methods being discussed ... or they wouldn't be discussed! No need to explain if it's obvious to everyone else! :) |
|
541 posts
|
@milkshake exactly :) |
|
56 posts
|
Heh. But then you have yet another page. ;) My thought was that "There's already an About page; why not just extend it?" My testing indicates that it's the same number of DB queries either way, so "best practice" would probably be whatever is more intuitive for the editor. Personally, I'm a fan of keeping related items on one page, which is why I suggested what I did. ;) Is there a third way of doing things? ;) |
|
27 posts
|
So I decided to go with putting it as a part of the home page. It's not quite logical in this case, but easily explainable to the editor. Probably for larger sites with more of these random pieces of content I would follow David's idea, creating a "Misc" page with children for each piece of content. I think having these random pieces of content probably indicates a problem with the site design/structure, but that's another story :) |