Search

Jonas, et al.

There’s indeed a lot of very good information in the forums etc. The difficulty for us newbies is in finding the best pieces. A thread like this is very valuable.

I recently found this out myself, mining the discussions for ‘the static content-pages challenge’. There’s a lot of different discussions and possible solutions in the form of extensions available but it’s quite difficult to filter the info.

I learned that the ‘static content-pages’ questions is being asked quite often. For these often encountered gotchas, a ‘tips’ or ‘FAQ’ or ‘Cookbook’ section would have been very helpful.

The same goes for the extensions. I’m guessing there’s a set of ‘favorite extensions’ people use in almost every project. Then there are multiple extensions doing basically the same thing and obviously they’re not all created equal.

I would suggest updating the ‘Featured Extensions’ in Downloads with these most-used extensions. What would be even better, of course, would be a download-counter combined with a simple rating mechanism. This would instantly give us an overview of most-used/favorite extensions, both allowing us to discover helpful new ones (rather than just browsing through them all) and guiding us to the currently best solutions…

Thanks for starting this thread, I’m very pleasantly surprised with the active and helpful Symphony community.

PS: I really wish you’d actually use #Symphony on IRC though ;-P

For these often encountered gotchas, a ‘tips’ or ‘FAQ’ or ‘Cookbook’ section would have been very helpful.

Thanks for the feedback. Nailing down these recurring questions I think will be one of the goals of the docs working group (and this thread), so it’s good to see it’s already useful. The next step will be distilling all the answers to those FAQs & tips into more concise documentation.

Hi David, those are great suggestions. A similar approach could be taken for forum discussions themselves (maybe with a vote up or down system like Reddit, or even just a “Popular Discussions” link that would sort discussions by most comments or most views.)

@JonasD exactly. Insight in popularity of discussions, extensions, etc. would really benefit new Symphonians.

We had the idea long ago that “seminal” threads would have a moderator close/lock it by posting a synopsis or conclusion which could then act as documentation. Some threads around here get mighty long, and information is quickly lost. I’ve started linking more to “definitive” threads on certain subjects (to save re-typing an explanation all over again) but I have a hard time finding them.

The reality is that I think these seminal threads should be used as a basis for writing documentation. A stop-gap would be a way to list these definitive threads. But I think they should be used as indicators of where the documentation is lacking.

Should we be locking threads more often, once they are closed? Do you find the re-opening of threads months or years later (when someone has a similar problem) useful or annoying? Does it make sense to keep it all in one thread, or for us to have locked the answered original thread and simply refer people to these?

The reality is that I think these seminal threads should be used as a basis for writing documentation.

That’s the exact purpose of this very thread.

That’s the exact purpose of this very thread.

Cool. Was just saying that although a way to “vote up” useful forum threads might be useful, they aren’t as sustainable or manageable as docs in the future.

  • Implementing search here, here, here and here (the reality would probably be a series of documents on how to choose the best approach for search, and the variety of ways to implement: DS filters, extensions etc.)
  • Caching (Data Source and Cachelite extensions, as well as using a Dynamic XML Data Source to cache a Symphony XML page)

Do you find the re-opening of threads months or years later (when someone has a similar problem) useful or annoying? Does it make sense to keep it all in one thread, or for us to have locked the answered original thread and simply refer people to these?

As someone who mostly asks the questions (compared to answering them), I find old threads very helpful and somewhat “affirmative”. It’s quite helpful to know a similar or the very same question has been addressed before, and if the answer isn’t quite clear to me, I can and will ask for further clarification. Plus, sometimes I don’t really know what my problem is, so I will search the forum to get an idea of what might be going on – and then continue the discussion in the thread I think appropriate. So for me, I find reopening old threads useful indeed.

On another note, I must admit I had nearly never looked into the documentation for help. Somehow I couldn’t shake off the feeling of the documentation”not being up to date” and/or “not being very comprehensive”. Imagine my surprise when I actually did take a look at the doc. and found exactly what I was looking for. I sure hope these twisted thoughts of mine aren’t too commonly shared, so that this working group’s improvement work doesn’t have to prove the documentation being a great place to look for resources in the first place!

Maybe we should be referring forum threads to the documentation wherever possible then!

What might be handy is at the bottom of the documentation having a section that’s, “Here are some related discussions in our forum” with up to 10 similar threads.

One that might be handy for people who are going to make larger sites would be the thread on XSLT performance gotchas. Though, this could be part of the over-arching topic of “Symphony For Large Sites” where you talk about what Symphony offers for those big projects and mentioning as a side note, “Here are some performance tweaks you can make to your XSLT.”

Somehow I couldn’t shake off the feeling of the documentation”not being up to date” and/or “not being very comprehensive”.

What if the doc articles had ‘Reviewed /Revised for version X’ data connected to it? It seems like we’ll need to track this anyway, since the docs will be an ongoing process that evolves as Symphony does.

What if the doc articles had ‘Reviewed /Revised for version X’ data connected to it?

ashooner, I like that idea. Adding data that gives some kind of clue to when the information was supplied / revised would give the reader a sense of actuality.

Maybe we should be referring forum threads to the documentation wherever possible then!

Yes! :)

^— was just going to suggest this one. excellent basic intro to something that is supremely useful.

I have no resource to offer, but what I would like to see is a good tutorial on suggested workflow using Git and the Symphony community of developers. Eg forking, push/pull etc etc. As a lone developer, I use SVN. I want to use Git to take advantage of all the features I keep hearing people talk about, but I don’t know where to start when it comes to distributed development…

Git and XSLT are both big topics on our list. Page 1 of this discussion has some good Git resources living in the forums — you might read through this thread if you need to get started right away.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details