The list of languages supported by Syntax Anywhere is absolutely enormous.
If your required programming language is not supported by one syntax processor, have a look through some of the other syntax processors and you will almost certainly find it in one of them. That is one of the reasons why Syntax Anywhere is pluggable and provides so much choice.
Some syntax processors can detect a language automatically. With other syntax processors you may need to provide a hint by adding a language="language_name" attribute to the containing element.
If If you can't find a suitable syntax for your language, try a language with similar syntax.
As with language syntaxes, Syntax Anywhere provides a massive choice of highlighting themes across the different syntax processors. The examples listed on these pages are just a tiny subset of those available.
Within Syntax Anywhere the available highlighting themes are generally identified automatically from manifests provided by CDN sources or by parsing directory listings. Some highlighting themes look better than others for some languages.
If in doubt, start with or go back to the default theme for your selected syntax processor. This will give you confidence that the syntax processor and language are highlighting correctly.
Then look for a highlighting theme that both works well with your Concrete CMS site theme and looks good for the languages you are working with.
The default settings of Syntax Anywhere are great for cutting and pasting code fragments into Atomik or Elemental and closely related Concrete CMS themes. But sometimes its a little bit more tricky than that. If you are getting no syntax processing at all, or syntax processing is not formatting correctly, here are a few things to check and try.
As a confidence builder, you can try a couple of really simple syntax processors. The Plain Lines processor does just that. The Diagnostic processor will return what Syntax Anywhere is selecting from the page and show it so you can double check what is actually being processed.
For developers, there is also a setting on the Advanced tab to output JavaScript diagnostics to the developer console, though that is mainly for my benefit if things are really getting tricky.
In the Selection tab, check the Overall Container selector. This needs to select an element that wraps content in your theme. If in doubt, open the developer console on the Main area of a page and look outwards for the overall wrapping elements and their classes.
Where sections of code are wrapped in <pre> and <code> elements, sometimes the theme formatting for these elements overrides the syntax. On the Tag Correction tab, you can check to remove surrounding <pre> or <code> elements, so freeing Syntax Anywhere and the various syntax processors to do their thing.
As an alternative, you can also use [code].....[/code] markers to wrap your code fragments.
You can exclude sections by CSS selector in the block dialogue. Or if you need to be extremely specific, you can add the class syntax-anywhere-exclude to any element and Syntax Anywhere will ignore it and any of its child elements.
In addition to their internal functionality, many of my addons make use of facilities provided in others to enhance their own capabilities. The consequence is that occasionally an update to an addon will depend, where another of my addons is installed, on an update to the other addon.
Hence:
Before installing, please ensure existing installed addons are updated.
The main way Syntax Anywhere can mess with JavaScript in another block is when you use the [code]...[/code] method of specifying syntax areas. Behind the scenes, Syntax Anywhere does some rewriting of the html to facilitate [code] sections, and doing so can result in other JavaScript event handlers becoming detached.
The simple solution is to not configure Syntax Anywhere to look for [code]..[/code] on any page containing JavaScript heavy blocks. Use any of the other methods of declaring sections to be highlighted such as <pre class="syntax_anywhere">...</pre>.
You can see Syntax Anywhere working on the same page as blocks that involve quite complex JavaScript on this site.
You can also exclude a block from any consideration by Syntax Anywhere by wrapping it with the class "syntax-anywhere-exclude" or specifying an id or class for the block in the Exclude section of thye Syntax Anywhere edit dialog.
What we mean here is an internal code exception in an addon or the core when you click the install button from the Add Functionality dashboard page or when you visit a page after installing an addon package.
If you experience such an issue, here are a few things you can check that may resolve the problem.
If you experience a code error on or immediately after install and need assistance, please use the Get Help link from the addon marketplace page to report the problem. On the Whoops report, click the [copy] button immediately below the error message. That will provide a stack trace you can paste into the help request and save time having to request that report later.
A windows system can throw an exception about cache path length. The full message will be something like "Cache path exceeds Windows PHP MAX_LENGTH of 260 characters" and the name of the exception is WindowsPathMaxLengthException.
This arises as a combination of ConcreteCMS and php internal issues. From JtFResources v2.19.32 we have a work-round for this by introducing the configuration value max_key_length in the file application/config/generated_overrides/jtf_resources.php. On windows, this will be automatically set to a value suitable for most windows installations.
If you experience the above exception:
In general, keep the value of max_key_length as high as practical for your installation. The ConcreteCMS core applies a hashing algorithm to all cache keys and a longer value for max_key_length reduces the (already extremely small) probability of cache key collisions.
Perhaps you are unable to connect your site directly to the ConcreteCMS marketplace to install an addon or theme. This manual install or update process works for all addons and themes - not just mine.
The process is exactly the same for addons and themes, except themes have an extra step of activating the theme after installing.
Sometimes step 3 above can run out of PHP execution time. This is most likely when installing an addon or theme that installs a large amount of sample content. You should not run into such an issue with any of my addons or themes.
If you do run into such issues, you can run the install manually from the shell command line.
$ concrete/bin/concrete5 c5:package-install my_package_handle
or
$ concrete/bin/concrete5 c5:package-update my_package_handle
When updating, be sure to replace the previously installed package directory rather than adding to it. If not, you could end up accumulating obsolete debris from a previous version of the package. In general you should not uninstall - uninstalling will loose existing data and blocks. Just replace the /packages/_addon_handle_/ directory with the unzipped package update.
If you find yourself often needing to install or update many addons or themes manually, consider my Package Magic addon. Once Package Magic is installed, through the marketplace or manually, all further installs can be handled from the site dashboard using Package Magic. If you build custom code in packages, Package Magic can do a lot more. Package Magic can analyze package structure, zip up packages, upload and download zip files directly to various stores.