I'm looking for information about how the Live Url (Absolute Url on the back end) regenerates and what triggers it to update.
Using Kentico 12SP MVC I have a pretty normal NewsArticle page type that uses a custom url pattern of "/news/{% UrlSlug %}" to route to an article. It was previously using AliasPath but because the content editors wanted the ability to create slugs that would be longer than the 50 character limit we created a custom field for it.
On any page that I create from scratch and many newer pages that I've edited this works out just fine and changing the UrlSlug to the desired (very long) slug updates the url. On a huge number of older articles though it appears that changing the UrlSlug has no effect on the Live Url. On many the url has changed to just "/news/" and others it's still showing as the old url (based on NodeAlias). I can still route to the page by hand typing the UrlSlug based url, but I've been using the TreeNode.AbsoluteUrl which is based on the Live Url (afaik) to generate menus and sitemap items and those are all still refusing to update on a large portion of our articles.
Hopefully someone knows how to force them to all regenerate or at least has a clue why some would be working and others not.
The "Live URL" displayed on the Page "General" tab is sourced from CMS.DocumentEngine.DocumentURLProvider.GetAbsoluteLiveSiteURL(TreeNode node);
Eventually that calls out to DocumentURLProvider.GetUrlInternal(TreeNode node);
You can override this with a custom DocumentURLProvider by registering a custom provider.
This would let you call the base.GetUrlInternal(node) and see what that is returning.
One conditional that is checked in the original DocumentURLProvider is NodeIsContentOnly, which is in the CMS_Tree table.
So I would check and make sure that all the pages with issues have this set to true (1 in the db column), otherwise the traditional Portal Engine Live URL generation takes effect.
At no point is there any 'regeneration' of Live URLs. What is displayed is coming from the values of the Page Type configuration (URL Pattern), the Node in the db, and the value populating the Macro Expression in your URL Pattern.
Related
I have a form built in Kentico and want to change the form action to point to a marketing automation vendor website (eloqua) to process the form. I noticed that there's no way to change the Action on the Form app, so I thought of using js to replace the action dynamically. I'm not sure whether it'll work, but another immediate problem I have is the field name/id generated by Kentico is so long (> 70 characters - e.g. p$lt$ctl02$pageplaceholder$p$lt$ctl03$On_lineForm$viewBiz$Company$txtText) and exceeds the length allowed by the vendor. Is there a way to shorten those names/ids?
To clarify, the reason I need to edit the name because the vendor allows to map (copy/paste) html name to whatever name it's using. I've tried pasting the whole string from one Kentico field and got the error message of exceeding character limit.
First part of the question, how do i direct a form to submit to another site?
In ASP.Net, the only way is to use javascript to alter the 's action url. Since you want to be careful where you edit this, i would use jQuery to replace the "Submit" button on your form with a javascript function that will alter the form before submission (so you don't mess up other postbacks)
$("button.MySubmitButton").click(function() {
$("form").attr("action", "http://TheVendor.com/PostLocation");
});
Next question is to alter the field names. If you absolutely MUST have form element IDs sub 70 characters, you will have to use Javascript again and it will break any postback-related functionality of the elements, so make sure the form is "as is" before doing it.
Again there is security concern because when you post to another location, you are sending ALL the data, including hidden asp.net inputs that contain viewstates and the like. You may want to take the time to 'eliminate' right before you submit any field that you don't want sent to the other site.
Something like this (Test it out a bit first though)
$("input:not(id*='txtName'):not(id*='txtEmail'),select:not(id*='ddlQuestion')").remove();
As #trevor-j-fayas points out, you can use javascript to point a form action to another url. While this does work you may end up writing a lot of javascript to not only point the form to a new url but also to do some data massaging (changing id's, doing url formatting, etc) before sending it to the target.
Additionally you lose some of the benefits of using a Kentico Form because the data never actually gets submitted back to Kentico such as email alerts.
I have worked in a similar scenario where were we sending data to Eloqua but instead of doing it client side we did it from the server by using either:
The OnOnAfterSave event on the BizForm control itself
The global BizForm submit hook BizFormInfo.TYPEINFO.Events.Insert.After
After the form is submitted to Kentico, our custom hook code runs which sends the data to Eloqua. In either hook you can fully access the Form metadata, field names, and submitted values. You can then craft an HTTP POST request and submit it asynchronously using a class such as HttpClient.
Is not a good idea from the architecture stand point and most likely not going to work without opening a huge hole in their vendor web site security. First of all how are they going to process the from if they don't know the field names, what if form fields change etc. Secondly you going to run into hell of trouble trying to submit form one site to another etc. What if the vendor site is not responding etc.
What you need to do is submit the form back to kentico web site i.e. process it on kentico web site and send email notification with results to marketing automation vendor website (the easy way for now) and redirect user to vendor web site.
Redirection and email - you can do out of the box without any programming. Actually to do all the above requires no programming and you get all the information recorded on your Kentico site.
Is it possible to hide the URL of the action of opening or editing a document in a XPage?
I am trying to avoid this:
http(example)://notesdev1.my_company.com/po/po.nsf/%24%24OpenDominoDocument.xsp?databaseName=CN=My_Company_NotesDev1/O=HCI!!PO%5CPO-data.nsf&documentId=E879C68A9A88F6DD87257BC6005A0748&action=editDocument"
I don't think you can use site documents for URL's that open specific documents. I started out customizing the 'Default Action' and 'Document id' of the Document data source. I then switched and tried rebuilding the URL in the beforePageLoad event, and using context.redirectToPage but it still shows the long URL.
I would like to know if I can have control over the entire URL, and still direct pages as I see fit. I know that I can't stop a user from Bookmarking, but if I can control the URL, I can prevent the user from bookmarking intermediate steps in a wizard, and also avoid ugly URLs.
You can use a website document to mask those long urls. Your short url needs to have the DocId visible and then you can map it by a substitution rule.
The other option is to compute your data source. You set it to ignore request parameters and use your own:
http://yourserver/some.nsf/thexpage.xsp?doc=unid
Then use the context to retrieve the Unid and compute
I've read a bit on the matter of friendly urls and I'm a little unsure as to what is better.
I currently have my website using a structure of http://www.domain.com/page.php?id=2
I am using the record id to determine the content of the page. My record id's are numeric and increment for new pages added. The content of existing pages can change completely over time. But, still use the same record id (this is a cms so the client may do this).
The way I understand it I have two options for friendly urls:
http://www.domain.com/page/2
http://www.domain.com/some-text-describing-the-page
Now because I identify the content by the record id, I would assume the first option would make more sense.
My client seems to want option two.
After some reading I found two conflicting points.
As per Tim Berners-Lee (the architect of the WWW) he states that you want a URI which will have the potential to remain the same 2 months, 2 years, 200 years from now. So you DO NOT want to use a page title or something similar for your pages. If you change your pages content you are either forced to change the content and leave the URI alone, or change the URI and are stuck with dangling links. You can read his article here (http://www.w3.org/Provider/Style/URI)
However, a number of other people on the internet (with no know authority to me) clearly state that you need to have a descriptive yet short URI for the best SEO value. From what I read, mostly for the purpose of backlinks and having keywords in the anchor text since people just use the link itself for the anchor text. So having keywords in the link itself helps search engines know what the link is about without a custom title.
It seems to me the difference has to do with long term VS short term.
Am I grasping this correctly?
If I am to use a slug style URI as defined by the user, do I have to just allow my user to type in whatever they want to a field and check against the current database to see if it exist? If so, am I supposed to anticipate static links by running a query for the know record id and then use the result to generate the url which would just be rewritten back to the format: http://www.domain.com/page.php?id=2?
It seems to me that would be a lot of extra overhead.
I would suggest something in the middle of those two:
http://www.domain.com/page/2/some-text-describing-the-page
or without page:
http://www.domain.com/2/some-text-describing-the-page
You can still get page Id from the Url, and there is a title as well! And what even more important, you're still able to get correct content, even when page title change later.
So think about situation like that: User creates a page, it receives Id=4 and it's title is My great title. From that information Url is generated, and is e.g. http://www.domain.com/page/3/my-great-title. After 2 months user changes the title to This title is better then the last one!. Url changes as well to http://www.domain.com/page/3/this-title-is-better-then-the-last-one. However, there is still 3 within the Url, so you're able to show right content! You can also check, if the rest of Url is actual, and redirect (301 would be the best one) to new one to let search engines know, that Url changed.
Whenever I save or create a node of a certain user-defined type, I am back in the edit window instead of switching to the first tab labeled view. All my fields (body, title etc. are as they were and no message appears, neither directly on the page nor in the watchdog database log. The validation is working, though, because I see those 'required' messages as soon as I try to save without Title for example.
The strange thing is that when I create a new content type, or use the predefined story and page types, I can edit and create nodes. In the latter case, Drupal answers with an 302 redirect, whereas with the proplematic content types, only a 200 HTTP status is returned.
The issue doesn't seem to be related to either JavaScript (on or off, no difference), Browser (tried Chrome and Firefox) or WYSIWYG (used input formats with and without).
I'm using Drupal 6.22 and the CCK. I have about 7 content types, some of them with fields. I am not using Rules, but a multitude of modules, all of which are up-to-date. I will post a list if this issue can't be solved otherwise.
I have spend the last hours trying to figure this out, both by looking at my installation (settings, database) and by searching Google & Co.
Any ideas?
The situation appeared because Drupal translated both the Upload and the Save button to one word, Speichern. The FileField issue tracker contains the corresponding thread: http://drupal.org/node/684426
The ImageField and Locale modules, along with a language such as German or Finnish were partly responsible for the trouble.
I need to count the page impressions of every page on a TYPO3 site into the db.
So I think I need an extension which is called on every page impression and increase a column 'impressions' in the db of the specific page.
I'm new to typo3 and new to extension development as well. Is there a way to include an extbase-extension on every page so some php-script get called?
(Update)
I want to add more information:
I don't need a counter which counts all PIs. The counter needs to be page-related. So it make sense to extend the pages-table from Typo3. Another need is that the extension should be done with extbase.
I'm new to typo3 and new to extension development as well. Is there a way to include an extbase-extension on every page so some php-script get called?
Once your plugin is configured you can include it with page.1234 < plugin.tx_yourextension_pi1 on any page. 1234 determines the position on your page.
The script should be USER_INT, so it's not being cached (mind you, this will cost loads of performance as previously stated by #norwebian)
As you don't want to output anything, make sure the controller stays empty as well.
Did you do a quick search in the extension repository? Trying a search for "page counter" reveals four relevant extensions.
"Sys_stat" is the closest thing to an "official" solution, it is really just enabling a few settings already existent. It has been reported to fill up the database with too much data, though.
"Generic Visitor Counter" would be my favourite, I believe (if I was going for a page counter at all), it is recently updated and seems simple enough.
You should really consider a proper stats extension, though. Both ics_awstats and ke_stats have been in my toolset.
YMMV. Be aware that if your site is popular, stats gathering quickly gets out of hand. On the other hand, if you go for a simple counter, including uncached extensions will cost performance.
I am not sure if I really understood what you want and need. After all, page impressions are not the same as page views. I wouldn't know the difference "onpage" right now though. So am I right in assuming that you mean page views?
If yes: I would take the following approach:
A separate, autonomous extension with a JavaScript for asynchronous calling of an API and a table for storing page views / page impressions.
Each page globally binds a JavaScript that initializes itself.
Once the DOM is ready, it sends a call to an AJAX API endpoint with the URL of the page as a parameter.
The endpoint takes only the URL.
For each unique URL, a record including counter is created or updated.
Extending the table for the pages doesn't make sense to me. What are you doing with a website that consists of news overviews, news details, press and blog sections, a dealer search and a store with product pages?
I would keep the statistics table standalone.
If you expand the table a bit and add date and time - no simple increment of hits - you can even identify the hottest pages of the week, the month, etc.
--
My approach won't increase/delay page load time much, if at all, and will have little noticeable impact even on heavily requested websites.
With the AJAX endpoint, it's then up to you how you deploy it and how much of the CMS framework you want to load.