I inserted a custom field in the article edit page in the administration - I changed two files:
In /administrator/components/com_content/models/forms/article.xml
I added a field subtitle
<field name="subtitle" type="text" label="Subtitle"
description="Add a subtitle here" class="inputbox" size="30"
required="true" />
and in administrator/components/com_content/views/article/tmpl/edit.php
I added
<?php echo $this->form->getLabel('subtitle'); ?>
<?php echo $this->form->getInput('subtitle'); ?
Now I've created my custom field. But I have to store the values in the database when I input and save something, how does it work?
Can anybody help me?
Thanks
If you add a field to the #__content table, it will probably be saved automatically. However I would not do that. You never know what an update does and you don't want to loose data.
If you look at /administrator/components/com_content/controllers/article.php you find a function called postSaveHook. This is where you can process the data further. There you could store your subtitle into an own table.
Anyway, you would need to apply those changes after each Joomla update, as it's likely that those files are overwritten.
I know the question is not recent, but as others may find it I think it is important to clarify something.
By extending the article's form xml in the way you describe, you are hacking the core files. This is bad practice and should be avoided. As Bakual explained, these changes are likeky to be overwritten with an update of Joomla.
Not updating Joomla when new Security updates are released is even worse - don't go there.
What you should have done is extending the article's form xml in a way that doesnt interfere with core files. This article given an example on how to go about this: http://docs.joomla.org/Adding_custom_fields_to_the_article_component
Related
I am in the process of fitting Sitecore Web Forms for Marketers to a solution. For that to work I need 3 things:
The ability to inject JavaScript from a rul
Rewriting all generated code to use Foundation (instead of Bootstrap)
Be able to read the submittet data of a "changed" form. Ie. a form where there is injected extra field through JavaScript.
My initial questions for this is to the second point: How do I write these views?
I have followed this article: http://www.hhogdev.com/blog/2015/september/customizing%20wffm%20in%20sitecore%208.aspx but unfortunately He does not elaborate on how to generate proper names/ids for fields and the form.
Can anybody point me in the right direction for that?
The blog post you linked to was written based on Sitecore 8.0, and although the module is the same the implementation of WFFM has since changed (unfortunately for the worse IMO).
We are currently using WFFM with Foundation, so it is possible to have them both working together but there are a few things you have to do.
I config disable Bootstrap CSS, this will mean Bootstrap markup but without the CSS files being included. I suggest you style around the given settings as much as possible to save future upgrade issues:
<settings>
<setting name="WFM.EnableBootstrapCssRendering">
<patch:attribute name="value">false</patch:attribute>
</setting>
</settings>
If you need to edit the markup then the default views for the form field markup files can be found under: Website\Views\Form and the EditorTemplates folder under that. Here's the kicker. In versions earlier than 8.0 update-5 the markup did not use the Bootstrap helper and therefore the markup was all present. The latest implementation hides this all away and therefore harder to edit in my opinion.
If you struggle with the Bootstrap markup then take a look at the view files from WFFM 8.0 update-5 or earlier. The markup is much more obvious and you should be able to (essentially) port these over to Sitecore 8.1 and then amend the markup as required (although we have found added the correct surrounding foundation DIV's were enough)
I have no idea what you mean by point 1, but for point 3, you can't. WFFM only works on the fields that you create on the back end, any new fields you create with JS will get lost. If you need to do something clever then use a hidden field (this requires adding a custom field type unfortunately) and then populate this hidden field with the data that you need passed back to the server.
Question: Can anybody let me know on how to clear a sitecore xslt cache?
Problem : We have implemented Main Navigation and Footer Navigation from the same items in Sitecore.We had a urgent requirement to remove an item from Main Navigation and Footer.
We removed the item from Main Navigation by unpublishing the item in sitecore.However footer is implemented using XSLT as below :
<sc:xslfile visible="true" runat="server" id="xslFooter" cacheable="true" varybydata="true" />
Now even though the item is unpublished,it is still visible in the footer of the site and my guess is, it is because of XSLT cache.So can you please tell me on how this can be done.
Note:I can't write any code for this now as I need to remove immediately from live site.Also I can't clear using admin tool as it clears cache for all users?
So any solution for this?
Thanks,
Suhas
If you go to /sitecore/admin/cache.aspx you will be able to clear the cache, but I assume this is the admin tool you don't want to use.
You say that you don't want to clear the cache for all users, but I can't see a way around this because the cache is not user/visitor specific.
If acceptable, you can also clear the XSL cache by renaming/updaing/adding a file in the XSL folder.
The issue has been discussed here:
Sitecore XSL cache
I want to create a simple registration form as one of the pages in my Joomla 2.5 website.
Every where on the internet, I see people asking me to use an extension like proforms, ckforms etc.. Most of the have price tags on them and the free ones do not have database and I don't really want a lot of functionality.
I just want the following code to work. So that I can pull the POST variable and insert them in a db.
<form method="post" action="mycreatedpage.php">
<input type="text"/>
<input type="submit">
</form>
Is this not possible in Joomla 2.5?
After a bit more searching, I realized that what I really needed was an ability to make PHP run inside the article. Thanks to a video.
Answer :
Install Sourcerer to enable PHP inside joomla articles
Create an article which take in the POST variable and insert into the database. This is the tricky part. What I did here was take the general PHP code which I would have written in register_do.php and insert it using the Sourcerer plugin.
Now create an menu Item which points to the above article. Save the menu item and copy the alias. This alias will be the action for the form.
From here on on, everything must work fine.
For more detailed instructions, watch the video
When you post a form, you have to have some code to handle the form input and what to do with it. So your options are to write a component to handle that form input or to use a form component that does it for you. If you write your own there is a lot to consider unless you want to open up gaping security holes in your website.
There are plenty of free forms components available. If you want free, I would recommend Chronoforms, if you don't mind paying small fee then RS Forms.
I'd like to know if anyone has had experience of using rendering parameter fields in Sitecore to store content. If so, what drawbacks are there?
In some respects, this seems like an attractive idea as you can add a sublayout to a page numerous times without needing to create child items and setting each sublayout's datasource to one of these child items.... however putting content into renderings fields has a few disadvantages:
This solution is not localizable since the renderings field is shared, so no good for multi-language sites.
To edit the content (if using the content editor) you need to switch to the presentation tab, click details, select the sublayout then edit the rendering parameters which is all a bit cumbersome.
Are there any more serious consequences of adopting this approach?
There is no way to apply workflow to the fields.
There is no way to enable the fields for the page editor.
You can accomplish this just as easily by using the Page Editor and setting a Datasource Template and Datasource Location on your sublayout.
I'll reiterate something you already pointed out -- it's a shared field, so the content can't be localized.
There's no way to reuse the content stored in parameter fields.
Even if you DID do it, its hard to get the data from the parameters because they are XML-based (hint: add an Image to rendering parameters and look at what value you get back)
Overall, you are breaking the separation of content and presentation that the layout field is intended to provide. Please don't do this, one day a developer following in your footsteps will come across it and then spend all day on http://nooooooooooooooo.com/.
I am quite new to django, and I have built a small page using forms.
When I go to the template and use the template tags, such as:
{{form.q}}
everthing is fine, and I see the form input field. However, I do not really like the input "box" it provides and I want to override this feature.
So, in my HTML, I would have something like:
<input id="customfield" name="q" type="text"/>
I tried the above, and everything seems to work fine. However, if I use for example:
<input id="customfield" name="{{form.q}}" type="text"/>
it dosent work. So, my question is:
[1] Is it ok to use name="q" or how can one specify {{form.q}} if I have a custom input?
[2] Are there any disadvantages (like sql injection) when using name="q" as opposed to simply using {{form.q}}?
Sorry for the 101 questions!
This is exactly how you would build a form if you wanted this much control in the template.
You'd take this course when other django shortcuts have failed, like one of the build in widgets that determine the way your field is rendered.
Update: after reading your comment, if you just want to inject attributes to the input element, you can pass the widget a dictionary containing attribute:value pairs.
q = forms.CharField(widget=forms.TextInput(attrs={'class': 'foobar'}))
SQL injection is irrelevant here (you'd worry about this when a user has something to do with SQL written on your server) and there are no disadvantages, aside from the code being more difficult to write and maintain.