just a comprehension question (again I will need relevant code much
later):
Is there a way to "select" certain articles which are then presented
defaultlike in a list always on display in the "section/root topic
template"?
I don't mean feature articles, because those I'd like to use
differently. I mean articles which need to be displayed in each issue
in the same place of the main template which people reach when calling
the overview of a theme of subjects. Somewhat like FAQ articles of the
specific theme (= section/root topic).
I know I could probably do this with feature articles, but I'd rather
not use that system. Maybe this could be hardcoded, but again, a
dynamic solution would be preferable.
If - as I suspect - I can do this with the topic function, is it also
then possible to EXCLUDE topics from the navigation template you sent
me, Mugur? Because of course I do not want that displayed among the
other topics of the navigation. Only as a box of links with FAQ-like
articles.
> Is there a way to "select" certain articles which are then presented
> defaultlike in a list always on display in the "section/root topic
> template"?
>
> I don't mean feature articles, because those I'd like to use
> differently. I mean articles which need to be displayed in each issue
> in the same place of the main template which people reach when calling
> the overview of a theme of subjects. Somewhat like FAQ articles of the
> specific theme (= section/root topic).
> I know I could probably do this with feature articles, but I'd rather
> not use that system. Maybe this could be hardcoded, but again, a
> dynamic solution would be preferable.
I believe you can do a topic-only solution, but if I were you, I'd also
consider using a separate section for each of your faq articles and then
link it to a topic. E.g. If topic is Tulips, list x articles from section
Flowers.
My thinking is, if you are using the section structure already for some
basic content organization in the backend, you may well have a place(s)
where such FAQ-like articles live, and then connect them to your
topic-driven site.
Just an idea. (and btw, there is also the Section Description, for each
Section, which you may also consider for your purposes).
Create a section without a corresponding root topic (e.g. "Static content")
in your first issue. Give it a bigger number, to split it from the other
sections (e.g. 1000). In there you put articles like: "About us", "FAQ" etc.
Remember the article number after you create it. Here is the code to display
those articles. Just paste it wherever you want to display one of these
articles:
I could have used names instead of numbers:
{{ set_section name="Static content" }}
but then this would not have worked for other languages than English. The
same for article.
Replace "Full_text" article field in {{ $campsite->article->Full_text }}
with the content field name from your article.
Mugur
On Sun, Aug 2, 2009 at 1:20 PM, pippa wrote:
> Hi,
>
> just a comprehension question (again I will need relevant code much
> later):
>
> Is there a way to "select" certain articles which are then presented
> defaultlike in a list always on display in the "section/root topic
> template"?
>
> I don't mean feature articles, because those I'd like to use
> differently. I mean articles which need to be displayed in each issue
> in the same place of the main template which people reach when calling
> the overview of a theme of subjects. Somewhat like FAQ articles of the
> specific theme (= section/root topic).
>
> I know I could probably do this with feature articles, but I'd rather
> not use that system. Maybe this could be hardcoded, but again, a
> dynamic solution would be preferable.
>
> If - as I suspect - I can do this with the topic function, is it also
> then possible to EXCLUDE topics from the navigation template you sent
> me, Mugur? Because of course I do not want that displayed among the
> other topics of the navigation. Only as a box of links with FAQ-like
> articles.
>
>
> Cheers,
>
> Pippa
>
>
>
MR> Create a section without a corresponding root topic (e.g. "Static content")
Errr - impossible.
These "static" articles are normal newspaper articles in every
respect, they already are in a section and a (root)topic, EXCEPT that
they are selected to represent the rubric best and provide the basic
info to understand the rubric.
But I've been thinking now that I can do it also by hardcoding them
into each section/root topic template, there aren't that many of them
and that way I don't have to twist my brain with how I assign them to
each section/root topic. Hardcoding is probably much faster than
giving each a different topic and then calling the different topic in
each section template.
stmo> Just an idea. (and btw, there is also the Section Description, for each
stmo> Section, which you may also consider for your purposes).
So instead of hardcoding the links into the template, I could hardcode
them into the section description? Yes, that also would be a solution
I believe.
Do these articles that describe the rubric best, change with each issue, or
are they more like static text, that stays the same regardless of new
issues?
Mugur
On Tue, Aug 4, 2009 at 7:10 AM, pippa wrote:
> Hello Mugur and Sava,
>
> Monday, August 3, 2009, 11:42:27 PM, you wrote:
>
> MR> Create a section without a corresponding root topic (e.g. "Static
> content")
>
> Errr - impossible.
>
> These "static" articles are normal newspaper articles in every
> respect, they already are in a section and a (root)topic, EXCEPT that
> they are selected to represent the rubric best and provide the basic
> info to understand the rubric.
>
> But I've been thinking now that I can do it also by hardcoding them
> into each section/root topic template, there aren't that many of them
> and that way I don't have to twist my brain with how I assign them to
> each section/root topic. Hardcoding is probably much faster than
> giving each a different topic and then calling the different topic in
> each section template.
>
> Cheers
>
> Pippa
>
>
>
MR> Do these articles that describe the rubric best, change with each issue, or
MR> are they more like static text, that stays the same regardless of new
MR> issues?
These articles have been written for various past issues and got
defined (by the newspaper chief editor) as being the "must-read
articles" of the relevant rubric to achieve a basic knowledge of what
the rubric talks about.
They then form a list of articles, which gets displayed on all pages
of that very same rubric, e.g. in one of the navigation columns. When
people go to a different rubric, that list changes to what is relevant
to that rubric.
Practical (fictious) example...
Rubric (=section=roottopic):
flowers (shows list A)
subjects (=topics):
roses (shows list A)
tulips (shows list A)
lilies (shows list A)
Rubric (=section=roottopic):
dogs (shows list B)
subjects (=topics):
spaniels (shows list B)
poodles (shows list B)
terriers (shows list B)
List A:
- Fertilizer Use in Spring
- Watering Techniques
- Natural Pest Control
List B:
- Basic Training for the Puppy
- The Best Showcuts for Your Dog
- Important Food Supplements for Old Dogs
After these articles are defined to belong to such a list they stay
there also for further (future) issues.
As an afterthought to the possibility of hardcoding: does that mean
the translations of these articles won't display? The Newspaper will
be translated into 3 languages.
It's simple: in the article type edit screen (admin menu: Configure->Article
Types->Fields) add a field of type "Switch", let's name it
"defining_articles". Usually this field will be unchecked (off) for regular
articles. You will have to check it (switch on) for articles that must show
up there all the time. In the section page add a list of articles before the
list of articles filtered by topics:
{{ assign var="prev_topic" value="0" }}
{{ if !$campsite->topic->is_root }}
{{ assign var="prev_topic" value=`$campsite->topic->identifier` }}
{{ set_topic identifier=`$campsite->topic->parent->identifier` }}
{{ /if }}
{{ list_articles length="x" ignore_issue="true"
constraints="defining_articles is on" order="byPublishDate desc" }}
display the article (like in the previous list)
{{ /list_articles }}
{{ if $prev_topic > 0 }}
{{ set_topic identifier="$prev_topic" }}
{{ /if }}
In the list of regular articles add this constraint: "defining_articles is
off". E.g.:
{{ list_articles .. constraints=" ... defining_articles is off" }}
In your example you will get a list of articles that will stay there all the
time, regardless of the issue:
List A:
- Fertilizer Use in Spring
- Watering Techniques
- Natural Pest Control
After this list the regular articles list will show up.
Mugur
On Tue, Aug 4, 2009 at 4:01 PM, pippa wrote:
> Hello Mugur,
>
> Tuesday, August 4, 2009, 1:34:46 PM, you wrote:
>
> MR> Do these articles that describe the rubric best, change with each
> issue, or
> MR> are they more like static text, that stays the same regardless of new
> MR> issues?
>
> These articles have been written for various past issues and got
> defined (by the newspaper chief editor) as being the "must-read
> articles" of the relevant rubric to achieve a basic knowledge of what
> the rubric talks about.
>
> They then form a list of articles, which gets displayed on all pages
> of that very same rubric, e.g. in one of the navigation columns. When
> people go to a different rubric, that list changes to what is relevant
> to that rubric.
>
> Practical (fictious) example...
>
> Rubric (=section=roottopic):
> flowers (shows list A)
>
> subjects (=topics):
> roses (shows list A)
> tulips (shows list A)
> lilies (shows list A)
>
> Rubric (=section=roottopic):
> dogs (shows list B)
>
> subjects (=topics):
> spaniels (shows list B)
> poodles (shows list B)
> terriers (shows list B)
>
>
> List A:
>
> - Fertilizer Use in Spring
> - Watering Techniques
> - Natural Pest Control
>
> List B:
>
> - Basic Training for the Puppy
> - The Best Showcuts for Your Dog
> - Important Food Supplements for Old Dogs
>
> After these articles are defined to belong to such a list they stay
> there also for further (future) issues.
>
> As an afterthought to the possibility of hardcoding: does that mean
> the translations of these articles won't display? The Newspaper will
> be translated into 3 languages.
>
> Cheers,
>
> Pippa
>
>
>
>
>
Sheeeeeeeesh! Campsite doesn't cease to astonish me!
Just one question: what will happen within the issues that this
(switched on) article is originally written/assigned to? Will it
be displayed normally as an article there? Or only as a link in the
list there as well?
And we really need to take note of these tidbits and gather them as
samples for the manual, they are such valuable advice.
Being an article it can show up in any article list; it's up to you to
define the switch meaning and from here, to filter articles in different
lists. The statement "list_articles" without any constraints will list all
articles from the current section and issue, including those with
"defining_article" switch on. So the "list_articles" statement is very
generic; you have to give it a meaning by specifying certain constraints
that select only the articles you desire.
If you had the time and will to help us with documentation we would be very
grateful.
It's a wonder we have this manual, which I think is much bigger and detailed
compared to most free software applications. The manual was written by me
(more than 50%), Sava and others. So more than half of the manual was
written by a "geek", a developer with no manual writing experience. I wish
we had somebody to help with the manual and demo templates, but we didn't. I
hate that demo templates too, but we didn't have anybody to help with this.
So I really don't care for anybody criticizing our lack of documentation but
not willing to help or pay for support (like the emails we received last
week, I won't name the person). After all, this is free software. One would
pay dearly to get this kind of application and support from a commercial
company.
Mugur
On Tue, Aug 4, 2009 at 6:06 PM, pippa wrote:
> Hello Mugur,
>
> Tuesday, August 4, 2009, 4:30:35 PM, you wrote:
>
> MR> It's simple: in the article type edit screen
>
> Sheeeeeeeesh! Campsite doesn't cease to astonish me!
>
> Just one question: what will happen within the issues that this
> (switched on) article is originally written/assigned to? Will it
> be displayed normally as an article there? Or only as a link in the
> list there as well?
>
> And we really need to take note of these tidbits and gather them as
> samples for the manual, they are such valuable advice.
>
> Cheers
>
> Pippa
>
>
>
MR> Being an article it can show up in any article list; it's up to you to
MR> define the switch meaning and from here, to filter articles in different
MR> lists. The statement "list_articles" without any constraints will list all
MR> articles from the current section and issue, including those with
MR> "defining_article" switch on. So the "list_articles" statement is very
MR> generic; you have to give it a meaning by specifying certain constraints
MR> that select only the articles you desire.
Okay - so this means I can use "list_articles" normally in the
template, plus I do a (real) list, e.g. in the righthand column, where
the switched-on articles of that section will be displayed at all
times? This would be absolutely perfect! Exactly what I want.
MR> If you had the time and will to help us with documentation we would be very
MR> grateful.
I am already taking notes about what I am doing and what possibilities
are for doing that. I always take such notes, so as to be able to
recreate my steps at a later time.
It is no problem, once I am done with adapting Campsite to the
production sites I work on, I can of course write examples for how
each thing was achieved.
MR> It's a wonder we have this manual, which I think is much bigger and detailed
MR> compared to most free software applications. The manual was written by me
MR> (more than 50%), Sava and others. So more than half of the manual was
MR> written by a "geek", a developer with no manual writing experience. I wish
MR> we had somebody to help with the manual and demo templates, but we didn't. I
MR> hate that demo templates too, but we didn't have anybody to help with this.
MR> So I really don't care for anybody criticizing our lack of documentation but
MR> not willing to help or pay for support (like the emails we received last
MR> week, I won't name the person). After all, this is free software. One would
MR> pay dearly to get this kind of application and support from a commercial
MR> company.
I already said to Sava, once I come up with working templates I can
write versions of them which you can offer for downloading. I've no
problem with that. As I most probably will do one in basic html and
one in pure CSS, that would give people two more templates. I can
throw in a couple of newspaper designs alongside with the templates,
also no problem. I've done that for other opensource CMS I regularly
use as well.
As to support, I truly have no axe to grind, so far you found nifty
solutions for every problem I had, and as I said above, it will be no
trouble writing these solutions up and adding them to the manual. The
other currently active developers of sites ought to also keep track of
such code snippets and write them up once the project is done, so
future users may profit. I've also come across a template which would
be very interesting for a collection (www.kindsein.com) offered to
users. Maybe someone could ask the authors whether they'd contribute a
disambiguated version?
What Campsite currently still lacks is a wide participating public,
but I am sure that will also happen in time. There's still too little
known about its capacities, which indeed are quite astonishing.
Yes, you can use list_articles for pretty much however you want, giving it
totally different meanings with different constraints. So you can list
regular articles in the middle using " is off" constraint in
the middle list and " is on" constraint in the right list.
There are quite a few sites using Campsite but up to now we didn't have any
significant contributions in terms of demo templates and examples. Yes,
Campsite needs a participating public, but in general a small part of the
users share their work and since Campsite, being a specialized application
has a small community we get few contributions. If you had any suggestion on
how to motivate Campsite users to share we would be glad to put them in
practice.
Mugur
On Tue, Aug 4, 2009 at 8:03 PM, pippa wrote:
> Hello Mugur,
>
> Tuesday, August 4, 2009, 5:40:51 PM, you wrote:
>
> MR> Being an article it can show up in any article list; it's up to you to
> MR> define the switch meaning and from here, to filter articles in
> different
> MR> lists. The statement "list_articles" without any constraints will list
> all
> MR> articles from the current section and issue, including those with
> MR> "defining_article" switch on. So the "list_articles" statement is very
> MR> generic; you have to give it a meaning by specifying certain
> constraints
> MR> that select only the articles you desire.
>
> Okay - so this means I can use "list_articles" normally in the
> template, plus I do a (real) list, e.g. in the righthand column, where
> the switched-on articles of that section will be displayed at all
> times? This would be absolutely perfect! Exactly what I want.
>
> MR> If you had the time and will to help us with documentation we would be
> very
> MR> grateful.
>
> I am already taking notes about what I am doing and what possibilities
> are for doing that. I always take such notes, so as to be able to
> recreate my steps at a later time.
>
> It is no problem, once I am done with adapting Campsite to the
> production sites I work on, I can of course write examples for how
> each thing was achieved.
>
> MR> It's a wonder we have this manual, which I think is much bigger and
> detailed
> MR> compared to most free software applications. The manual was written by
> me
> MR> (more than 50%), Sava and others. So more than half of the manual was
> MR> written by a "geek", a developer with no manual writing experience. I
> wish
> MR> we had somebody to help with the manual and demo templates, but we
> didn't. I
> MR> hate that demo templates too, but we didn't have anybody to help with
> this.
> MR> So I really don't care for anybody criticizing our lack of
> documentation but
> MR> not willing to help or pay for support (like the emails we received
> last
> MR> week, I won't name the person). After all, this is free software. One
> would
> MR> pay dearly to get this kind of application and support from a
> commercial
> MR> company.
>
> I already said to Sava, once I come up with working templates I can
> write versions of them which you can offer for downloading. I've no
> problem with that. As I most probably will do one in basic html and
> one in pure CSS, that would give people two more templates. I can
> throw in a couple of newspaper designs alongside with the templates,
> also no problem. I've done that for other opensource CMS I regularly
> use as well.
>
> As to support, I truly have no axe to grind, so far you found nifty
> solutions for every problem I had, and as I said above, it will be no
> trouble writing these solutions up and adding them to the manual. The
> other currently active developers of sites ought to also keep track of
> such code snippets and write them up once the project is done, so
> future users may profit. I've also come across a template which would
> be very interesting for a collection (www.kindsein.com) offered to
> users. Maybe someone could ask the authors whether they'd contribute a
> disambiguated version?
>
> What Campsite currently still lacks is a wide participating public,
> but I am sure that will also happen in time. There's still too little
> known about its capacities, which indeed are quite astonishing.
>
> Cheers,
>
> Pippa
>
>
>
I'm also glad to help and contribute as I have said before. Something
small I have already done but surely can do more. I think we have a
rising nice feeling here among the support forum people and that means
that people are willing to give back as they have got so much.
Manual itself is quite nicely working platform and those contributed
examples and short coding samples can be given there as notes.
What comes to the support forum, it could be probably structured
differently although for me this way of being able to write emails
instead of going physically to the forum has been very nice. Anyhow we
could have some very distinctive categories for different type of
questions there. In that way we could search better the history of
questions by other people before asking the same question once again.
* Overview
* Screenshots
* Features
* FAQ
* Download, Demo
* Who's Using
* Manual
* Support
* Free support / Forums
* Paid support
* Sample templates and add-ons
* Developers
* Bugs
Above is one example how it could be structured. The indented ones
mean that they would be sub-level pages.
When the site is more summarized in the main issues and go straight to
point, it creates a nice feeling for a beginners approaching the
system. Just my 2 cents today.
Comments allowed and appreciated.
/Sanna
On 4.8.2009, at 20.57, Mugur Rus wrote:
> Hi Pippa,
>
> Yes, you can use list_articles for pretty much however you want,
> giving it totally different meanings with different constraints. So
> you can list regular articles in the middle using " is
> off" constraint in the middle list and " is on"
> constraint in the right list.
>
> There are quite a few sites using Campsite but up to now we didn't
> have any significant contributions in terms of demo templates and
> examples. Yes, Campsite needs a participating public, but in general
> a small part of the users share their work and since Campsite, being
> a specialized application has a small community we get few
> contributions. If you had any suggestion on how to motivate Campsite
> users to share we would be glad to put them in practice.
>
> Mugur
>
> On Tue, Aug 4, 2009 at 8:03 PM, pippa wrote:
> Hello Mugur,
>
> Tuesday, August 4, 2009, 5:40:51 PM, you wrote:
>
> MR> Being an article it can show up in any article list; it's up to
> you to
> MR> define the switch meaning and from here, to filter articles in
> different
> MR> lists. The statement "list_articles" without any constraints
> will list all
> MR> articles from the current section and issue, including those with
> MR> "defining_article" switch on. So the "list_articles" statement
> is very
> MR> generic; you have to give it a meaning by specifying certain
> constraints
> MR> that select only the articles you desire.
>
> Okay - so this means I can use "list_articles" normally in the
> template, plus I do a (real) list, e.g. in the righthand column, where
> the switched-on articles of that section will be displayed at all
> times? This would be absolutely perfect! Exactly what I want.
>
> MR> If you had the time and will to help us with documentation we
> would be very
> MR> grateful.
>
> I am already taking notes about what I am doing and what possibilities
> are for doing that. I always take such notes, so as to be able to
> recreate my steps at a later time.
>
> It is no problem, once I am done with adapting Campsite to the
> production sites I work on, I can of course write examples for how
> each thing was achieved.
>
> MR> It's a wonder we have this manual, which I think is much bigger
> and detailed
> MR> compared to most free software applications. The manual was
> written by me
> MR> (more than 50%), Sava and others. So more than half of the
> manual was
> MR> written by a "geek", a developer with no manual writing
> experience. I wish
> MR> we had somebody to help with the manual and demo templates, but
> we didn't. I
> MR> hate that demo templates too, but we didn't have anybody to help
> with this.
> MR> So I really don't care for anybody criticizing our lack of
> documentation but
> MR> not willing to help or pay for support (like the emails we
> received last
> MR> week, I won't name the person). After all, this is free
> software. One would
> MR> pay dearly to get this kind of application and support from a
> commercial
> MR> company.
>
> I already said to Sava, once I come up with working templates I can
> write versions of them which you can offer for downloading. I've no
> problem with that. As I most probably will do one in basic html and
> one in pure CSS, that would give people two more templates. I can
> throw in a couple of newspaper designs alongside with the templates,
> also no problem. I've done that for other opensource CMS I regularly
> use as well.
>
> As to support, I truly have no axe to grind, so far you found nifty
> solutions for every problem I had, and as I said above, it will be no
> trouble writing these solutions up and adding them to the manual. The
> other currently active developers of sites ought to also keep track of
> such code snippets and write them up once the project is done, so
> future users may profit. I've also come across a template which would
> be very interesting for a collection (www.kindsein.com) offered to
> users. Maybe someone could ask the authors whether they'd contribute a
> disambiguated version?
>
> What Campsite currently still lacks is a wide participating public,
> but I am sure that will also happen in time. There's still too little
> known about its capacities, which indeed are quite astonishing.
>
> Cheers,
>
> Pippa
>
MR> Yes, you can use list_articles for pretty much however you want, giving it
MR> totally different meanings with different constraints. So you can list
MR> regular articles in the middle using " is off" constraint in
MR> the middle list and " is on" constraint in the right list.
Could I also use "list_articles" without a constraint in the middle
and with the constraint ""switch_name" is on" in the right list?
Because that would give what I wanted, normal articles in the middle
and the specified list in the right, right?
MR> There are quite a few sites using Campsite but up to now we didn't have any
MR> significant contributions in terms of demo templates and examples. Yes,
MR> Campsite needs a participating public, but in general a small part of the
MR> users share their work and since Campsite, being a specialized application
MR> has a small community we get few contributions. If you had any suggestion on
MR> how to motivate Campsite users to share we would be glad to put them in
MR> practice.
Oh, I wouldn't say Campsite is so specialized that only a few people
are interested. Check out the gathering Prosepoint (Drupal fork)
managed in a very short time. And they are, as I already said,
offering much less than Campsite.
And for a real publicity coup I would try to offer one of the better
known newspapers free development of a site with Campsite against
being prominently named.
"Could I also use "list_articles" without a constraint in the middle
and with the constraint ""switch_name" is on" in the right list?
Because that would give what I wanted, normal articles in the middle
and the specified list in the right, right?"
No, this would not give you regular articles in the middle list, but it
would give you ALL articles, *including* the special articles you want only
on the right column. Here is from my previous email:
So you can list regular articles in the middle using " is off"
constraint in the middle list and " is on" constraint in the
right list.
Middle list code:
{{ list_articles ... constraint=" is *off*" }}
Right list code:
{{ list_articles ... constraint=" is *on*" }}
Mugur
On Tue, Aug 4, 2009 at 9:39 PM, pippa wrote:
> Hello Mugur,
>
> Tuesday, August 4, 2009, 7:57:03 PM, you wrote:
>
> MR> Yes, you can use list_articles for pretty much however you want, giving
> it
> MR> totally different meanings with different constraints. So you can list
> MR> regular articles in the middle using " is off" constraint
> in
> MR> the middle list and " is on" constraint in the right list.
>
> Could I also use "list_articles" without a constraint in the middle
> and with the constraint ""switch_name" is on" in the right list?
> Because that would give what I wanted, normal articles in the middle
> and the specified list in the right, right?
>
> MR> There are quite a few sites using Campsite but up to now we didn't have
> any
> MR> significant contributions in terms of demo templates and examples. Yes,
> MR> Campsite needs a participating public, but in general a small part of
> the
> MR> users share their work and since Campsite, being a specialized
> application
> MR> has a small community we get few contributions. If you had any
> suggestion on
> MR> how to motivate Campsite users to share we would be glad to put them in
> MR> practice.
>
> Oh, I wouldn't say Campsite is so specialized that only a few people
> are interested. Check out the gathering Prosepoint (Drupal fork)
> managed in a very short time. And they are, as I already said,
> offering much less than Campsite.
>
> And for a real publicity coup I would try to offer one of the better
> known newspapers free development of a site with Campsite against
> being prominently named.
>
>
> http://www.koreaittimes.com/story/set-your-own-open-source-magazine-web-site
>
>
> http://seattlepost.wetpaint.com/thread/2480980/Rethinking+the+newspaper+content+management+system
>
> http://befused.com/drupal/drupal-for-publishers-notes
>
> And as I told Sava, you really need a good forum.
>
> Cheers,
>
> Pippa
>
>
>
I rewrite this email because the stupid forum software converted my bold
formatting into *off*. So middle list code:
{{ list_articles ... constraint=" is off" }}
- will list regular articles, filtering out the special articles
Right list code:
{{ list_articles ... constraint=" is on" }}
- will list only the special articles
So this code:
{{ list_articles }}
will list ALL articles, including the special ones.
Mugur
On Tue, Aug 4, 2009 at 10:00 PM, Mugur Rus wrote:
> "Could I also use "list_articles" without a constraint in the middle
> and with the constraint ""switch_name" is on" in the right list?
> Because that would give what I wanted, normal articles in the middle
> and the specified list in the right, right?"
>
> No, this would not give you regular articles in the middle list, but it
> would give you ALL articles, *including* the special articles you want
> only on the right column. Here is from my previous email:
>
> So you can list regular articles in the middle using " is off"
> constraint in the middle list and " is on" constraint in the
> right list.
>
> Middle list code:
> {{ list_articles ... constraint=" is *off*" }}
>
> Right list code:
> {{ list_articles ... constraint=" is *on*" }}
>
> Mugur
>
>
> On Tue, Aug 4, 2009 at 9:39 PM, pippa wrote:
>
>> Hello Mugur,
>>
>> Tuesday, August 4, 2009, 7:57:03 PM, you wrote:
>>
>> MR> Yes, you can use list_articles for pretty much however you want,
>> giving it
>> MR> totally different meanings with different constraints. So you can list
>> MR> regular articles in the middle using " is off" constraint
>> in
>> MR> the middle list and " is on" constraint in the right
>> list.
>>
>> Could I also use "list_articles" without a constraint in the middle
>> and with the constraint ""switch_name" is on" in the right list?
>> Because that would give what I wanted, normal articles in the middle
>> and the specified list in the right, right?
>>
>> MR> There are quite a few sites using Campsite but up to now we didn't
>> have any
>> MR> significant contributions in terms of demo templates and examples.
>> Yes,
>> MR> Campsite needs a participating public, but in general a small part of
>> the
>> MR> users share their work and since Campsite, being a specialized
>> application
>> MR> has a small community we get few contributions. If you had any
>> suggestion on
>> MR> how to motivate Campsite users to share we would be glad to put them
>> in
>> MR> practice.
>>
>> Oh, I wouldn't say Campsite is so specialized that only a few people
>> are interested. Check out the gathering Prosepoint (Drupal fork)
>> managed in a very short time. And they are, as I already said,
>> offering much less than Campsite.
>>
>> And for a real publicity coup I would try to offer one of the better
>> known newspapers free development of a site with Campsite against
>> being prominently named.
>>
>>
>> http://www.koreaittimes.com/story/set-your-own-open-source-magazine-web-site
>>
>>
>> http://seattlepost.wetpaint.com/thread/2480980/Rethinking+the+newspaper+content+management+system
>>
>> http://befused.com/drupal/drupal-for-publishers-notes
>>
>> And as I told Sava, you really need a good forum.
>>
>> Cheers,
>>
>> Pippa
>>
>>
>>
>
Tuesday, August 4, 2009, 9:00:10 PM, you wrote:
MR> No, this would not give you regular articles in the middle list, but it
MR> would give you ALL articles, *including* the special articles you want only
MR> on the right column.
Hmm ... probably a communication problem here ...
These articles are part of regular issues. I *want* them displayed in
their issues absolutely normally. If I use switch_off, then these
articles (which have the switch on) would not be displayed in the
middle in their own issue - yes or no?
I want that right list in ALL issues in the relevant section, it
doesn't matter whether in an issue where that article stems from it
appears in the middle and as a link in the right.
> So this code:
> {{ list_articles }}
> will list ALL articles, including the special ones.
and of course you can test it as well if it is exactly what you wanted.
I think Mugur's explanation of 3 different versions is a very good
summary, so those codes he gave explains the options:
1) regular + no special articles
2) no regular + only special articles
3) all articles
I think this is a good piece of simple code that we could take to some
manual page as well. Nice example: idea by Pippa, solution by Mugur.
Trying to help here that we woudn't exhaust Mugur et al. too much...
Sanna
On 4.8.2009, at 22.17, pippa wrote:
> Hello Mugur,
>
> Tuesday, August 4, 2009, 9:00:10 PM, you wrote:
> MR> No, this would not give you regular articles in the middle list,
> but it
> MR> would give you ALL articles, *including* the special articles
> you want only
> MR> on the right column.
>
> Hmm ... probably a communication problem here ...
>
> These articles are part of regular issues. I *want* them displayed in
> their issues absolutely normally. If I use switch_off, then these
> articles (which have the switch on) would not be displayed in the
> middle in their own issue - yes or no?
>
> I want that right list in ALL issues in the relevant section, it
> doesn't matter whether in an issue where that article stems from it
> appears in the middle and as a link in the right.
>
> Cheers,
>
> Pippa
>
MR> I rewrite this email because the stupid forum software converted my bold
MR> formatting into *off*. So middle list code:
MR> {{ list_articles ... constraint=" is off" }}
MR> - will list regular articles, filtering out the special articles
MR> Right list code:
MR> {{ list_articles ... constraint=" is on" }}
MR> - will list only the special articles
MR> So this code:
MR> {{ list_articles }}
MR> will list ALL articles, including the special ones.
Yes, so I grasped that correctly in the first place.
Just drop off that preview_button definition and you'll be done. Hope
this helps!!
Cheers,
On Tue, Aug 4, 2009 at 3:55 PM, Generare Management
Department wrote:
> Hi!
>
> How do I remove the button "Preview" in our comments form?
> I guess it relates to this line:
>
Of course! Thanks. I didn't realise to look the beginning when the
button is in the end of the page.
That solved it.
/Sanna
On 5.8.2009, at 0.06, Holman Romero wrote:
> Hi Sanna,
>
> How does the comment_form opener tag looks like?
> I bet it has something like this as attribute:
>
> {{ comment_form ... preview_button="Preview" ... }}
>
>
>
> Just drop off that preview_button definition and you'll be done. Hope
> this helps!!
>
> Cheers,
>
>
> On Tue, Aug 4, 2009 at 3:55 PM, Generare Management
> Department wrote:
>> Hi!
>>
>> How do I remove the button "Preview" in our comments form?
>> I guess it relates to this line:
>>
{{ /comment_form }}
>>
>> but where is the php controlling, creating these buttons of
>> "submit" and
>> "preview"?
>>
>> BR, Sanna
>>
>
>
>
> --
> /holman
> Oh, I wouldn't say Campsite is so specialized that only a few people
> are interested. Check out the gathering Prosepoint (Drupal fork)
> managed in a very short time. And they are, as I already said,
> offering much less than Campsite.
Yes, you are right. And I am kicking myself for not doing much more earlier
to promote Campsite. We are indeed open source's best kept secret for all
intents and purposes. By far and wide, people don't even know we exist.
> And for a real publicity coup I would try to offer one of the better
> known newspapers free development of a site with Campsite against
> being prominently named.
Well, no lunches come free, someone would still have to pay for the free
development (or it would have to be done but many small hands). But it's a
good idea. Meanwhile, the best way anyone can help is spread the word, a
good word or two or ten.
Capitalizing on the current momentum of the discussion and taking a cue
from one of Sanna's ideas below (better categorization of issues addressed
here). I am changing the subject line. Please read on.
Generare Management Department wrote on
08/04/2009 08:23:45 PM:
> Manual itself is quite nicely working platform and those contributed
> examples and short coding samples can be given there as notes.
For starters, let's start collecting the code examples from the past few
days into the Campsite wiki. All they need is proper titles. I see the wiki
as a staging phase, once polished, it goes into the manual proper (and
meanwhile link from the manual to it). In the beginning, we'll have some
circular references (manual sends you to the wiki, which sends you back to
the manual), but hey, that's what hypertext is all about . The reason I
am favoring the wiki use is that we'll be moving to a new manual management
platform anyway (flossmanuals.net) and it's easier to master than our
beloved Docmint. Doug will start this process, I'll help too. All others
(excluding Mugur, Holman, and Sebastian -- they'd better have some time for
coding) willing to help, please request a wiki login (Sanna already has
his, and has contributed in the past indeed
> What comes to the support forum, it could be probably structured
> differently although for me this way of being able to write emails
> instead of going physically to the forum has been very nice. Anyhow
> we could have some very distinctive categories for different type of
> questions there. In that way we could search better the history of
> questions by other people before asking the same question once again.
We use a combination of Sympa, mailman and phorum. Some call it organic
growth, but in plain English you call it a mess The immediate steps we
are taking to introduce some order are: an upgrade of Phorum (underway) and
the phasing out of Sympa. That by itself won't lead to better
categorization of questions (unless Phorum offers some nifty tagging module
or something), but maybe someone has some good solutions/ideas up his
sleeve.
> The Campsite home page should have - in my opinion - a bit more
> summarized navigation:
> http://www.campware.org/en/camp/campsite_news/
>
> * Overview
> * Screenshots
> * Features
> * FAQ
> * Download, Demo
> * Who's Using
> * Manual
> * Support
> * Free support / Forums
> * Paid support
> * Sample templates and add-ons
> * Developers
> * Bugs
There is a saying in Serbian (and I bet there is similar stuff in other
languages), a shoemaker always wears the worst shoes (the current
Campware/Campsite shoes are much more fashionable than we had a year ago,
before last Summercamp, but it was a hasty job). So all ideas in this sense
are welcome. So keep them coming (possibly under a different subject
Wednesday, August 5, 2009, 6:48:27 AM, you wrote:
stmo> Yes, you are right. And I am kicking myself for not doing much more earlier
stmo> to promote Campsite. We are indeed open source's best kept secret for all
stmo> intents and purposes. By far and wide, people don't even know we exist.
I've known about Campsite for years, but never was able to implement
it for technical reasons (no own server), for a long time it was one
of very, very few CMS capable of full UTF-8 based translation and user
rules. Reasons why I wanted to use it, most sites I build for my
clients are multilingual and managed by users living in many different
places. But I checked back only irregularly, as I knew it was
impossible to install on a shared host for so long. I bet there are
many out there who still think this is the case. E.g. I'd submit a
news story to sites like Slashdot to tell the IT world wide and large
that Campsite now will install on shared hosts as well. You might be
astonished how many may remember that they once were very much
interested by it.
stmo> Well, no lunches come free, someone would still have to pay for the free
stmo> development (or it would have to be done but many small hands). But it's a
stmo> good idea. Meanwhile, the best way anyone can help is spread the word, a
stmo> good word or two or ten.
Do check the last link I sent in my email, please:
Edipresse has 200 newspaper and magazine websites worldwide. In the
past 18 months, they have converted 11 websites to Drupal. They have
cut IT costs by 75% and traffic has grown by 220% as a result of using
Drupal.
I believe that if you contacted the people from Edipresse and
suggested that they test Campsite for one of their better known
magazines, all you'd probably have to do is set up and configure the
software itself. They do have their own or rented IT staff which could
do the design and implementation. As the basic installation and
setup is the trickiest part of Campsite, that alone would already be
sufficient help and possibly sell them on switching one of their sites
and publishing about it. I have no doubt, as I have looked at
ProsePoint myself before deciding to use Campsite this time, that
Campsite will stun them. It's the closest to commercial or
custom-built solutions. And just doing the installation and basic
setup should be feasible for one of the experienced coders of the
project without taking too much time. What would give you quite an
edge there is that they have many eastern country publications. And if
you could convince them into using Campsite for something like "Le
Matin", that would produce a real splash!
Another thing is to get serious IT magazines to write up about
Campsite.