In our old project we're using Alfresco 4.2.c community version.
There's a task page there, were you can use predefined filters to manage data you want to see.
I was able to add some extra filters there, anyway another problem stands in my way.
There's a paginator there, probably from YUI, which works by two parameters, maxCount and skipCount.
Right now it's configured to show max 400 records on one page.
I'm trying to add an option to display all records at once. Is anyone familiar enough with that system to even tell if it's possible? YUI framework is very hard to manage.
It seems like on every page or filter change it redirects you to ahref='#', a then a method reads the filter id and gives some extra parameters to the request. I can't find a way to maybe bind another button to reload the page in the same manner and just add another line to the request, which would make the paginator show all the records at one page.
Related
On the website I run we have a single search field where you can enter a name or profession. When you search you are served with a page full of results that come from 3 seperate sources.
Once you click on one field e.g. John Do, you will be taken to his page. On that page we have a back to search, but it goes to a blank screen.
I want to go back to the actual search results so the person doesn't have to do it all again, but I'm not sure where to start. Any suggestions?
That's a tricky situation.
There can be many solutions for this issue but I'll will name some of them.
Activate the cache of the pages (Quick trick, no suitable for websites that relies on users (*login)), you can go back and your form will be the same with the results without any issue.
Manage the load of the page of Jhon Do as a ajax load and #hashtag references, you don't reload the page but you just manage the states of the HTML. (Can be done with JS frameworks or React)
Depends on which platform are you working try to manage the variable of the search with this concept post-redirect-get
Hope that is helps!
Cheers.
I have a list of custom items of the same page type being displayed in a basic repeater with a page size of 1. I want to implement my own navigation for the back and forward through the items.
I tried using a Text / XML transformation so I'm not sure if I have to revert to using ASCX.
However DataItemCount works fine for the number of items but not the current "item" index. I have tried DataItemIndex and DisplayIndex which are always zero. I have tried accessing the current Pager (although ideally I want to hide this) but am not 100% sure how to reference it.
I also need to be able to navigate to the next and previous item. I'm sure I could make use of the querystring page parameter in a custom method but don't know how to write or how to call this. I am struggling to find examples which don't simply involve evaluating a column value.
It sounds like you need a carousel. I'd go with javascript solution for this: it is more efficient as it does not reload the page when you navigate between items.
You can also use this:
https://devnet.kentico.com/articles/previous-and-next-links-to-listed-pages
It for version 8.2, but with none or a little code adjustment it should work in any version.
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.
We are using Liferay as a classic CMS meaning that we compose pages using web content articles. There is an issue with Liferay's internal search I could not yet find a proper answer for:
Because web content articles are pretty much only building blocks for pages we don't want the search to show them as distinct items. The user should only get a list of pages that contain their search keywords, including all the articles put onto this page.
At the moment we can see two different approaches and both come with certain problems we could not solve yet:
Idea 1
We modify the journal indexer and try to obtain all URLs of the pages (how?) where the article has been placed on. Then we add them to the document to be indexed. In the search result we then can access the URLs and collect them. In the end we make sure every URL is only shown once.
Idea 2
At some point Liferay renders the entire page before sending it to the browser. If we somehow could put an indexer there, we could index the entire page. We then could limit the search to the special "page documents". Getting the fully rendered page would be the main issue here, because either we would have to run a crawler to frequently trigger this indexing or we would need to find a way to trigger page rendering from within an indexer or something like that.
I have been carrying this problem around for quite a while now and still could not find an idea good enough to spend time trying it out. If anyone of you has some input on those two ideas or maybe an entirely different approach, I would be extremely grateful.
I'll just answer myself, because by now we found a suitable solution to solve our problem:
In addition to the default search portlet there is also a "Web Content Search Portlet" shipped with Liferay. It seems to have been part of Liferay for quite a while now, but it's somewhat hard to find, because there is hardly any documentation for it (I only found the Liferay wiki page, which isn't really anything at all). It searches only within web content articles and shows links to the pages rather than just a link an isolated view of the article. It has much less configuration options than the default search portlet, however. Pretty much all it allows to change is whether articles actually have to be placed on at least one page to show up in the results.
So there is no need for any kind of custom indexer or any other "hack"...all we need to do is use the correct portlet. We will only need to write a hook that changes the appearance of the result page.
What you ask is interesting but your ideas are on the wrong direction.
Specially idea 2 it's particulary wrong because you cannot do indexing work meanwhile a page is rendered. Think about performace only.
In Liferay pages and assets are not directly linked: pages have portlets and portlets display assets (web content and more).
Liferay indexing refers and scans assets content, not refers the display result of the assets. Think about permission: the same page can display different contents depends on the user who looks.
bye
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.