• Content count

  • Joined

  • Last visited

  • Days Won


tpr last won the day on November 12 2017

tpr had the most liked content!

Community Reputation

2,540 Excellent

1 Follower

About tpr

  • Rank
    Hero Member
  • Birthday 06/21/1980

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    Budapest, Hungary
  • Interests
    sports, spaghetti, portable applications, and spaghetti

Recent Profile Visitors

6,540 profile views
  1. I'm not using twig but latte but the main advantages are sophisticated template inheritence, filters, reusable blocks/partials, etc, and after all, more readable and maintainable code. Backdraws are the small overhead and some extra complexity, of course the latter disappears when you get used to it. Markup regions is in my opinion a very simple templating implementation. This works fine if you don't need any of those extra features, and in case of template engines you can more easily find help if you are stuck. Speaking of myself, I made only my first PW project with pure PHP about 3 years ago, then all with latte.
  2. I'm not entirely convinced You would have to create those fields and remember their names if you need to add setRequired and such things. But it's an advantage if you willl save it to a page with the same fields.
  3. I've used this in a project and worked well, though it's not so simple to set up, and the client can easily mess things up.
  4. But how would you add validation rules, setRequired, showIf-like stuff and others? Surely these can be added somehow but it would be too cheesy. As I wrote, I wanted to have the fields to be in a separate php file, so I can reuse them in another project easily. The form processor part can be lengthy if it requires complex logic before saving to the DB, it's much cleaner this way. Plus the fields php file can also be lengthy, especially if you need to add custom (backend) validation functions too (in one such file I have 400 lines of code).
  5. Thanks, I will try this CSRF instead. No, the admin page is just holding the fields for messages, and it's also the parent page of the submissions. Form fields are defined in a php file, it would be very hard to map Nette Forms to fields. It looks like this: form page path: /forms/contact form processor: /site/templates/forms/contact.php form fields: /site/templates/forms/contact-fields.php I use a separate file for fields, this way it's easy to copy and include (to another project). Others: yes, everything is jQuery-free settings are defined at PHP level, and passed via data-xxx property. I need some special prefixes like "date::", "selector::" and such in certain cases, but perhaps this could be improved. process module: maybe, I do not know much about them
  6. There's $form->addProtection() in Nette forms but that always throws an error. How you managed to add this?
  7. This is what I implemented so far: ajax submit datepicker, autocomplete, autogrow, character counter add CSS classes to controls for better CSS targetting add date, ip and language to each submission I've also added a honeypot but on larger sites it doesn't seem to be effective. I need to integrate a captcha, this is one of the reasons I haven't shared it yet.
  8. I see your points - I started that way too. Then I realized it's much easier to handle multi-language strings like success message, etc so I added a GUI. I still think this is an improvement, I can make adjustments much easier in the admin when needed. But it's not a requirement, you can use it purely from code too. The form process part looks like this: if ($nfh->checkSuccess()) { $nfh->saveToPage($nfh->getTitle('name, email')); $nfh->sendAdminEmail(); $nfh->getResponse(); exit; } Here saveToPage, sendEmail, sendAdminEmail methods can have parameters so you don't need to use the corresponding admin page. If there's a page for it, then adding a form is as easy as $nfh = addForm(1066); echo $nfh->form; // or $nfh->renderForm() The module loads the form and form field files from page ID 1066 name. Anyway, I think I'll clean up it a bit and share as I see there's a need for it.
  9. Good catch! Just modified the module to allow loading both, thanks. (will be released later)
  10. Interesting, I can only think of an adblocker or similar that prevents loading the file.
  11. Perhaps it could help if you pasted the path you entered here.
  12. v1.8.5 is available, which contains @Robin S CKEditor Link Files CKE plugin, multilanguage-ready. @theo Have you managed to solve the issue? I couldn't find any relevant info on "Browser Network Analysis". Are you sure you entered a correct path?
  13. Nice, seems you had more time on this than me on my very similar module If you (or someone else) could devote enough time I can share my module that I have already started to polish. Perhaps you could merge the two or get ideas from it:
  14. Thanks, will do. I've just finished making it multilanguage-ready but need to check first on non-ML site too, though the way it's set up I don't expect any issue. I ended up adding multiple divs to the DOM containing the list of files, one for each language (#link-files-menu, #link-files-menu__1088, and so on). Then on menu toolbar click I get the current lang ID of the editor (from data-configname and ckeditor ID) and show/hide the corresponding menu. Update: see here
  15. You were on the right path but that file is only a sample. Copy it elsewhere to templates/scripts for example and load it in assetpaths. I don't know what is that, will do a search.