28 votesEvgeny Zaritovskiy responded
Thanks to Barbara, here is current workaround:
TO ADD A SITEMAP.XML to a WA SITE:
Create a new folder under file mangement called sitemap.
Then upload your site map to this folder.
Sumbit your site map to Google, it will look something like this yoursite.com/resources/sitemap/sitemap.xml
A good place for free google sitemaps is:
Night generated sitemap.xml file. I read many people looking for sitemap.xml functionality, and I would like to reiterate how important this is. I know it is possible to manually run a tool that scrapes the web pages, but that's manual and doesn't have the data that you have in the database. Instead, I would love to see a nightly task that builds the sitemap.xml by evaluating the change date of static content coupled with the dynamic content from gadgets. For instance, if a page had a gadget that is displaying a new discussion post, that page should be dated at least to when that post was made. The sitemap.xml file should (appear to) be in the root so search engines automatically find it. You could have an ISAPI filter or HTTP module that redirects domain.com/sitemap.xml based on the domain. There should also be a robots.txt file.
Dynamic content is currently linked with query string parameters. All pages should contain the header text in the url. For instance, instead of this..
It should, perhaps, be something like this which is much more search engine friendly. Note that the relevant Ids are at the end so the WA program can extract and use.
Online chat would be nice, with configurable chat rooms. I'd love to have a widget that could be placed in the header or footer (or near the menu) that displays either the count of people that are currently visiting the site (sessions) or the count of members currently logged in. The count of members could optionally link to a page with the list of members.
This would be very helpful!
Here's how I would love to see this implemented..
Custom Resource Not Found Page
Add a new functional page named, "Resource Not Found." Only one of these would be allowed. We can edit the content of the body, and optionally use a token to display the resource url to in the body. The page would be displayed with the full site chrome (menu, header, footer, and such) as any other page. This way, if a visitor is displayed an RNF, they will be more likely to stay on the site.
Add a new sub menu to the Web pages menu in the admin view named, "Redirections." Display a grid of paths and the page that each path should redirect to. The system should detect requests to one of these paths and send a permanent redirect to the path of the mapped page. Multiple redirection paths could be associated with any page, providing a lot more flexibility.
In general, I'd love to see a lot more grid edit support. Needing to individually open each page to edit things like title and description is very time consuming.
Resource Not Found Log
Add another sub menu to the Web pages menu named, "RNF Log". Each time the custom RNF page is displayed (as described above), add the time, resource path, and referrer to a log file (XML?). This tab would show the log in a grid. We could see the individual requests, but also view the grouped values (individual paths & counts, individual referrers & counts). The referrers would help us reach out to others to fix links when viable.
For any given resource path, we could use the interface to easily map it to a page going forward, which would be added to the Redirections tab.
There would be buttons to clear and export the log.
I'd love to see it implemented something like this, with individual modules.
Files.zip: The entire resources folder is captured in a ZIP file with the directory tree.
Configuration.xml: All configuration data is stored in a well documented, schematized XML document.
PageData.xml: The configuration and content for all pages is stored in a well documented, schematized XML document. Each page would be in a Page element with attributes for the type, meta tags, name, path, etc. a child element would exist for each of the content blocks.
UserData.xml: All user information is available in a well documented, schematized XML document.
Others for forum data, events, finances, etc.
All of the module files would be captured into a Backup-YYYY-MM-DD.zip file. An entire backup file could be selected and restored. However, a single module could be selected and restored. e.g. just page data. This would also provide a nice way to bulk import data. I imagine this would make it easier to move from other CMS systems to WA. Tools could be written to transform backups from other systems to WA's schema.
I agree with most of the people on this thread. An ability to backup and export the data is critical and should be top on the list. You mentioned that part of the complexity is due to incompatibility between versions of the site. Even if the standard operating procedure was to have all customers backup again right after a new release, that would be reasonable.
Even though it is not a direct implementation, I hope this could be helpful:
We just launched integration with Integromat platform, which helps to build automated workflows. We also provide several templates for quick start, and one of them allows to copy google calendar events into WA events. So if you share a google calendar for events submission, then the scenario could copy submitted events into your Wild Apricot account.
You can try this integration by this link https://www.integromat.com/en/integration/2275-copy-google-calendar-into-wild-apricot-events
Please add me to the list of people that feel this is a very important feature. The functionality, as documented here http://forums.wildapricot.com/forums/308932-wishlist/suggestions/8825554-members-to-be-able-to-submit-events-3764 , would work perfectly.
[quote user="Chief_Apricot"]Hi Jessie - sorry, we are not likely to tackle this feature in 2011.[/quote]
That's disappointing, especially since it was stated almost two years ago http://forums.wildapricot.com/forums/308932-wishlist/suggestions/8825554-members-to-be-able-to-submit-events-3764 that it would be implemented mid 2010, at the latest.
Is the prioritization process documented anywhere? I understand that you can use these threads to get a sense of how important each feature request is, but how do you gauge how we would prioritize each of these features against each other? There are features that have been delivered over the last year that, personally, I would not have prioritized higher than this one.
Have you considered using some kind of stack-ranking system that your customers could use to communicate relative priority of feature requests? I recognize that the features may vary greatly in effort to implement, and that you have other constraints such as development resource expertise, which also influence priority. However, such a system could help define the workstream, provide visibility into the process, and alleviate some of the frustration that I'm sure customers on this thread are feeling.