I would like to extend / override the login mechanism of the FELogin extension. AFAIK the FELogin extension just submit the entered data and the TYPO3 CMS authentication services handle the rest.
Does someone know which file I have to tinker with to change the authentification logic?
As you already wrote, felogin does only take care about:
rendering the login/logout
forgot password stuff
All other stuff happens in TYPO3 core and can be manipulated by writing a custom AuthService. There are a lot of extensions in TER which can be looked at if you need some examples.
For starting I would propose to look at some IP restriction extensions as those are the more simplier ones. The API didn't change much in later versions.
The docs can be found here.
Related
I need to create a Newsletter Subscription form in my typo3 site. And I want to just store the data in Typo3 so that we can use it later for Mailchimp or another NL Tool. Which is the most suitable extension for this? And I have tried newsletter_subscribe extension, but I m totally confused about how to do this. Please help me if anyone knows this.
My design is hereImage
I got an error when I try to configure this extensionimage
Any help is appreciatable. Thanks!!
When I see your image design, just a warning :it's good to keep it simple, but keep it GDPR compliant too, and don't forget the consent checkbox.
You can handle the subcription form with the form framework extension or powermail extension, because it's just a form. Both can store datas in the backend. I remember that powermail propose a double optin' behaviour which can be usefull for that kind of form subscription.
Also, if you finally want to handle everything in TYPO3 (I mean the newsletter email sending), luxletter is a good newsletter extension that is TYPO3 V10 compatible.
Cheers,
Rachel
I have to migrate TYPO3 6.2 websites to 8.7. Some websites use custom pibase extensions, do I need to redevelop them with Extbase ?
All previous answers have been correct but some words from a TYPO3 core team member: There are no plans to drop the support of "pibase" in the core. It is absolutely ok to use that API even though it does not provide much help to developers.
However I recommend to use at least fluid standalone to be able to create nice templates without all those ### stuff.
you don't need to redevelop these extensions, but you might need to change the call to core functions.
In 6.2 you still could use the old class names like t3lib.
These class names are available only with compatibility layer (together with a lot of delay).
For the future you need to use namespaces (and the correct new classes). You also should use namespaces for your own classes.
Depending on your used functions you might need to replace some calls with the newer functions as some functions got deprecated meanwhile.
You don't need to redevelop these extensions.
Just you need to change some TYPO3 core function like t3lib_div t3lib_BEfunc t3lib_parsehtml t3lib_extMgm and more..
Please see complete example here : See more details
Since version 3, plone.protect provides automatic CSRF protection.
Plone 4.3 includes, by default, plone.protect 2.0.
Can I just upgrade to start using this feature in Plone 4.3?
I have only a little experience with it and played around with plone.protect 3.x and Plone 4.3.2, but nothing serious.
I had also a lot of addons installed, so I cannot say if there were problems with Plone itself, or an addon.
Here are my notes:
Yes you can enable it, but your installation will stop work.
So... No you cannot :-)
First plone.protect.aut 3.0 handles every POST/GET request by default.
For example Session handling is a write request, so you have to fix this manually wherever it's in use!
Second writing data in annotations (IAnnotation), it's also protected by default, so have to find every place where annotations are used (For example Portlets storage) and fix it.
If your testing environment is in a good shape :-) you will get it work, but out of the box Plone 4.3 is not ready to use it.
Conclusion:
The main problem are GET requests, which ends up with a database change.
I now this is wrong but Plone 4.3 and/or mainly the addons have this behavior.
You will end up in extending the plone.protect.auto feature by a whitelist.
I wrote all the auto-csrf stuff. I would recommend against using it in Plone 4 unless you want to invest a lot of time into it.
Easiest way to fix using it on Plone 5 would be to add in some javascript that automatically protects almost everything for you when logged in. That won't deal with ZMI and then it depends on javascript to work.
JavaScript would do a couple things:
add the authenticator token to all forms that post back to the site
add the authenticator token to all admin urls that potentially do writes to the database. For instance, the "Edit" button does a write to the database because in Plone 4, AT Content Types makes a temporary object in the database. Also, it writes with locking support.
add authenticator token to all ajax requests. Use something like https://api.jquery.com/ajaxSend/ to add the token.
SOLUTION
Inline Relational Record Editing is the answer. Handy stuff.
For Documentation
:)
QUESTION
I created a front-end plugin using extension builder in TYPO3 6.1.0. For this plugin, extension builder of course generates few default forms in the backend. However, my intention is to have the forms customized. My plugin has 3 tables related it and all these have to be integrated to be inputted from one common form, than having individual forms, which is not ideal.
Do I configure my TCA stuff for this ?.. If so, please suggest me some good tutorials on that.
Or will using FlexForm do the trick ?...also please suggest some good tutorials.
I also checked out Flux, but did not quite understand the architecture of it.
Thank You :)
EDIT:
I want forms to give the user to fill in records. Lets say I have an extension for creating Calendar Events. I need a form, in the TYPO3 backend, through which an administrator can add events and its details.
I was wondering what is the best practice for creating forms in Wordpress? As a developer I hesitate to use a plugin like CForms, but I can understand why someone would like to use it. In the end I want to know the following:
What is the best practice for creating forms in Wordpress? (Custom HTML/CSS with Javascript and PHP validation or just using a specific aspect of the Wordpress API?)
I don't use any part of the WordPress API for forms. You could automatically grab the name and e-mail address out of the cookie WordPress creates when someone leaves a comment, if you want to try to auto-populate some fields.
An easy way to handle forms is to use Page Templates. That lets you create a new PHP file for a specific page, overriding the default page template of the theme. Then you can simply have the form post to itself and this one page template handles the processing as well.
http://codex.wordpress.org/Pages#Page_Templates
A lot of what's available for WordPress in the way of addins, and what gets a lot of attention, is stuff that I find makes little use if you have programming and general web skills. Almost always they seem to (necessarily) overgeneralize a requirement with a zillion options and configuration requirements because they are first of all designed for non- or barely-programmers.
Just learn the fundamental paradigms, scratch your head and wonder why nothing is consistently abstracted and/or encapsulated, get over it, and use what you already know about php and HTML-based forms. WordPress doesn't add much in the way of either tools or constraints.
I find the Widget feature applies usefully to most everything these days, and Forms is a candidate. But that's my own WordPress viewing prism - YMMV.
What do you mean by "in Wordpress"? Do you just mean placing the form HTML in a Wordpress template? Or storing data collected in the Wordpress DB? If you just want to create a form on your site, there's nothing Wordpress-specific to worry about. I believe there's some special Wordpress data facilities you can use if you're creating a widget or plugin or whatever they're called now. But if you're not, just create the HTML, and point it at a target URL that processes the values and puts them in a DB, Wordpress or otherwise. That target URL could be a separate PHP resource, or the same page. If it's the same page, you just need to include your PHP somewhere in the main Wordpress flow.