LostKobrakai

@Ivan Gretsky If you've needed it once you know the answer, maybe a quick look for the exact syntax, but that shouldn't be difficult if you know what you're searching.

Sorry to highjack the thread, but I had build a few forms yesterday and had the same problem. What I noticed is, that each field gets inserted in the same wrapper-elements, even the InputfieldMarkup. Is there a way to exclude some fields from getting these wrapper-elements?

$(document).ready(); is a jQuery function which is called after the DOM is fully loaded. This is indepentend of the framework you seem to use, as long as the jQuery libraray gets loaded.

There are some things wrong in this code. data: "country="+$("#country").val(), "province="+$("#province").val(), These commas aren't for seperating different data, but to seperate different datahashes in the object, like this: { name: data, name: data, name: data } Then you need to take a look at the jQuery docs, which types "data:" does accept and use: http://api.jquery.com/jQuery.ajax/ The important part: So you need to concat your data to a object, string or array and then pass it to data.

It shouldn't matter where your developing, as long as you don't hardcode anything. The only thing to change, if it's going live, is /site/config.php to reflect the new domain. Edit: For future reference, maybe the RewriteBase has to be changed as well, but this depends on the server configuration.

After setting the RewriteBase, this should work on every page, not just the homepage, as every link gets the /mysite.com/ prepended. ProcessWire doesn't require a specific place, as long as the RewriteBase is set correctly.

If the ajax call works, just return $_POST as a string from the backend and see if the right values get send to the backend. If there's something wrong with the ajax call, the send data shouldn't matter. Just try to debug both parts seperatly.

The beauty of relative urls is, that it's independent of it's domain. So you don't need to change anything, if you don't have any hardcoded url bits.

Has someone an answer to this question? I would like to make a membership number required but only for members and not for admins.

Sometimes you need to generate full urls, e. g. if you send emails. More generally, everytime the url should be used without the context of "this is the current domain", which the browser has, if you're already on the website.

I think adrian meant a more complex solution, where every deletable children would be removed and only the non-deletable ones and it's parents would stay, so that no pages get orphaned.

I'm currently trying to fork the ProcessUser module for a own custom table of products. But even though I've changed the parent page in the properties provided by the module, it doesn't save pages to the right location. If I hit "Add New" it saves the new page as a child of the Admin page. The url does even show the right ID of the page I want to have as parent. …/admin/produkte/add/?parent_id=1021 (ID of the adminpage is 1092) $properties = array( 'initSelector' => $selector, 'columns' => $this->showFields, 'defaultSelector' => "title%=", 'defaultSort' => 'title', 'parent' => $this->wire('pages')->get(1021), 'template' => $this->template, 'editURL' => './edit/', 'addURL' => './add/', 'delimiters' => array('shop_category' => ', ', 'manufacturer' => ', '), 'allowSystem' => false, ); Edit: Had a second look, the 'edtiURL' and the 'addURL' where the issue. Removing them created the expected behavior.

Have you tried to make the fieldsettab global as well? I would imagine that this would add it, but the order could be off.

I think he's talking about the bootstrap framework and not about actually bootstraping pw. @Juergen It would be nice if you could provide the code of your login process. Could it be, that your redirecting always to the default language's url?

The only other issue I can imagine to influence the language would be a language agnostic url. If you use a different url for the translated content, this will automatically change the value of $user->language to reflect the current page language. If this doesn't help with your issue, you should try to pin down when/where the language exactly gets reseted. Your title suggests, that before your login script the language is still the right one, even in the db, while after it's called, it's the wrong one. If you would provide some detailed information about the "before-login" and "after-login" state and the login script itself, maybe the issue can be tracked down to it's source.

So first of all, it seems your quite new to ProcessWire. You don't need to query the database to get the data, the processwire api does this for you. The query's on the thread I linked before where only to find the source of the misbehavior. If you need more information relating to the api have a look here: http://processwire.com/api/. To get the current language of a user you only need to look at "$user->language", which outputs the stored language. You can also set another language via the api like so. $user->language = $languages->get("default"); $user->save(); Unfortunatly in 2.4 seems to be an error in the code, which prevents saving of the right language in some cases. This is investigated in the thread I linked before.

This sounds a little bit like an issue I had a few weeks ago. Maybe have a look here: https://processwire.com/talk/topic/6751-setting-the-user-language-via-api/ It would also be good to know which version of processwire you're using to further investigate your issue.

I like the + and - icon. It's the clearest distinction between pages with and without subpages I've seen for the 2.4 admin themes.

The easiest way would be to select all repeater-fields which contain the date, sorted by it. With "$event = $repeaterPage->getForPage();" you can than get the corresponding event (kind of the parent of the repeater) for each of the dates.

yeah, didn't think of that. I have a imagefield below the rte for the insertable images and it would be so convenient to tell the client to just update the description fields without reminding to update the rte code. It would also be more visible, that the texts are missing on a page. The description texts won't be used for other things beside the alt text.

I don't know when multilanguage image descriptions made it's way into processwire, but the pwimage plugin for ckeditor doesn't use it, if the textfield is also multilanguage. It would be nice, if it would be aware of the different fields. Also is there a way to get the plugin to update the alt text, if the image description gets changed, this would be nice and convenient, especially for clients.

I think the problem in the current verion of processwire is, that published pages go live as soon as they are edited. If you really need to have a evaluation instance, which publishes changes, I think you'll also need a versioning system, where a draft and the current online version would be saved.

This would be a natural fit.

With no doubt, but in my opinion themes are not there to be universal, as they should be interchangeable.

The problem I see, is that even $page->body is used differently by different users. I have seen Ryan use it to store the whole html of the current page, which is than echo'ed into the pagetemplate, while I mostly use it for wysiwyg-content. So to reach interchangeability of themes, there needs to be a base agreement about the coding style which is used by the different themes. Edit: I don't think this would be a bad thing, as your module already does rely on the themes being catered for it, with the theme as module approach.