swissdoode

Naturally, after posting my question, I figured out a way (which is kinda cumbersome, though). I just reload the entire page content using $('body').html($('body').html()) This triggers all page load events again. But it also reloads all JS basically reloading the page. If there's a better way to do this (meaning, just re-initializing the form), that'd be great.

Hi everybody I'm loading an Inputfieldform via AJAX (rendering the form with $form->render(), passing it back to the calling JS and injecting it into the DOM). This basically works - but the javascript that handles inputfield-actions (like conditional display) is not initialized. How do I manually initialize the js-actions of the form? I found a javascript-file for each possible inputfield. But they're using only $(document).ready()-Events, which can't be called after an AJAX-return. Any ideas?

Hi everybody After some serious tampering, I was finally able to implement the «InputfieldPassword» in my Frontend. (interestingly, the field seems to be made for the BE only, so I had to manually add the JS/CSS files - took me a while to figure that one out). I'm using the Form-API to create the form, with this at the end: $passwordField = $modules->InputfieldPassword; $passwordField->attr('name', 'password'); $form->add($passwordField); The fields are being rendered, the criterias I set are working, too. When I fill in the form, the matching password-function recognises the 2nd password and indicates that the passwords match. BUT: When I hit the submit-button, I get an error telling me to «repeat the same value» pointing to the password-repeat-field (Javascript validation is turned on for the form, so the form doesn't get submitted, but the JS seems to validate the form). Why is that??? Am I missing something? See attached image for clarification. Edit: When I turn off the JS-validation, the form is submitted correctly (I'd like to keep the JS-validation, though).

First: I'm using PW 2.x for this (don't ask)... I'm trying to output an error with HTML-Markup, using this: $form->get($errField)->error($exception->getMessage(), Notice::allowMarkup); But the HTML-Markup that's in $exception->getMessage() is rendered with HTML-special chars. What am I doing wrong?

Ok, found it out... In the init-function of my module, I call $this->modules->get('JqueryUI')->use('modal'); Then I simply add «pw-modal» as a class to my link to the field-editor and viola, it opens in a modal window... Link for a new Field looks like this: <a href="/processwire/setup/field/edit?id=new&fieldgroup_id=new&modal=1&process_template=1&name=myTestField" class="pw-modal addNewField">New Field</a>

I'm trying to create a module that - among other things - provides a function to edit and add new fields. Instead of just linking to the regular field-editor, I want to open it in a modal window, so the user stays on my page rather than being redirected to the field-editor. I found the «AdminThemeDefaultHelpers» which look like they'd provide a way to do this, but when I try to implement that in my module, I get all sorts of errors... (Call to a member function get() on null in /web/wire/modules/AdminTheme/AdminThemeDefault/AdminThemeDefaultHelpers.php on line 15) This is the code I'm using to call the helpers: require_once(wire('config')->paths->modules. "/AdminTheme/AdminThemeDefault/AdminThemeDefaultHelpers.php"); $helpers = $this->wire(new AdminThemeDefaultHelpers()); The module itself is a backend module (extends Process implements Module, ModuleConfig) I'm pretty sure I'm doing something wrong... Any guidelines available on this topic?

Ok, got it... Apparently, the additonal class can just be added to the the php-file that contains the module... I was under the wrong impression that a module file can only contain one class...

Hi Forum While getting to know PW, a question about modules with more than one class came up. Let's say, I want to create a shopping cart module. I need two classes for it: - the shopping cart itself - a class for the items in the cart (I want to separate this because I want the items to have their own methods - for calculating a total, for example). Now, I don't think I can just add the item-class to the file where I create the cart-module. How would I do this in the module? Thanks for any help (and your patience with a noob

Thanks guys I still find it odd, but I can see the advantages. And thanks for pointing out the Page Field Select Creator.

Hi y'all I just read a tutorial about how to organize data in PW and raised an eyebrow on one particular topic. In the tutorial, a website for cars is built, with one of the attributes being the build-year of the car. It is suggested to use the pageField and create a top page with the attribute-title and sub-pages with the contents to choose from. So far so good and I can follow that. But for the building-year, this sounds weird. Assuming my year range goes from 1916 - 2016, I'd have to create 100 pages. Ain't that a little too much? I can see the advantages of this approach (selecting from the field, for example as discussed elsewhere in this forum) but just to create those 100 pages would take quite a while and even worse, for every new year I'd have to create another page. Is this really the best approach or do you guys have other suggestions?

Hi Forum I installed PW locally to get familiar with it, using one of the included demo-sites. It all worked until I checked the checkbox to create new thumbnails for the homepage (in the admin-tool). Now, whenever I try to edit the home-page, it seems like PW is doing tons of redirects and finally gives up and I'm presented with a «Connection interrupted»-error (in Firefox). I tried different browsers, with the same result. enabling the debug-mode in config didn't help either - no errors appear. Guess something with that thumbnail-generator is wrong, but how do I fix this now? Is there some process stuck somewhere? I just wanna be able to edit that page again... PW-Version 3.0.36 Apache on a Mac using ampps

Thanks for the mini-tutorial, bernhard I was more or less able to re-create what you described. Right now, I am able to create a new meta-tags page from within the super-page - but I can't edit it from there (this might be just because my setup is wrong, though). Although the functionality can be achieved like this, it is still cumbersome and kinda hard to maintain, not to mention that I'll have a separate page for just as little information as just meta-tags. I still have to add the field to every template and can't just make it global and thus having it on every page/template. I can't add it as a tab in the template like with the fieldset - the one thing I really like about fieldsets. If the workflow were as described by you and lostkobrakai, it would be somewhat ok, but as long as this isn't the case, this approach doesn't make much sense to me. To clarify things for me: even if I would, I couldn't create this kind of field-set-container whatever by creating a module or something?

@LostKobrakai Unlike bernhard, I don't understand what you're aiming at. Would you mind to enlighten me? Let's stick with my meta-tags example. I made a template called meta-tags and added the fields I made for this to it. Then I also created a page for it using this template... But: How do I add this template/page to other pages now? How do I tell PW to add the page to all pages? I'm confused... (sorry for the noob questions, btw).

Although this thread is somewhat «old», I'll add my two cents here from my experience as a new user: Following a short tutorial that taught how to add Meta-Tags for every page, I found two things: how to make a FieldsetTab and now to make fields global. To my surprise, I was able to make the fields global, but not the FieldsetTab. Which results in one template having a nice Tab grouping the Meta-Tag fields together and on all other pages they just linger around somewhere. This ain't a dealbreaker, but it surely isn't very handy either. All the suggested workarounds in this thread are just that: workarounds. I totally agree with bernhard and his usecases that such a functionality would be great to have and in some circumstances is even a necessity. And no, the template setup batcher isn't really an option, either, it's just another workaround that's unintuitive and cumbersome to use. It already hit me when I was introduced to PW that for bigger projects one accumulates a ton of fields and it occured to me that it gets pretty messy pretty fast. Grouping fields logically would be another great feature that would make the clusterf*** I witnessed on some of the projects that were showed to me much easier to handle. I'm far from being an expert in PW but one of the things that I read over and over by all the PW evangelists is its flexibilty. A.k.a. if you need it you can build it. But something that simple (and quite frankly very obvious) can't be built? I'm baffled, really...