LostKobrakai

Take a look at this: https://processwire.com/talk/topic/8697-module-jumplinks/

It's not the full path that matters, but the placement dependent on the domain, like you can read it in the link I posted.

If you mean drag and drop, that's already implemented.

Then maybe it's a bug. This feature was added somewhere around that time of your pw version, if I remember this right. It should be the right option.

Only being able to access the homepage directly is most of the time a issue with the .htaccess. Try to comment out the RewriteBase statements in this file. Use "/" if processwire is in the root of your domain and "/subdirName/" if its in a subdirectory. A more detailed explanation can be found here: http://processwire.com/docs/tutorials/troubleshooting-guide/page3

Locked is the right option for this, but is seems to be more descriptive in the newest dev version: Open when populated and not editable (locked). So to clarify this: Does your field hold a value?

@arjen There's always the option to remove certain fields with an own hooking module. It's just not as easy to set up.

I'm personally really not that interested in the development front of php. As long as I have to even switch servers of clients that the minimum requirements for PW are met I can't possibly benefit from anything mentioned there. I'm happy if I have php >= 5.4.

I've just added a new version of the module on the dev branch. A request for a single select inputfield powered by the chosen library came up on github. So I implemented it, which does mean the current inputfield is renamed to …SelectMultiple. I still want to add some more fitting styles, but it would also be nice to have some feedback if everything is still working for you guys, before I merge it to master.

Here you can change your forum name: https://processwire.com/talk/index.php?app=core&module=usercp&tab=core&area=displayname Here's the avatar upload: https://processwire.com/talk/index.php?app=core&module=usercp&tab=core (first listitem)

That's exactly what you want to have. wireRenderFile() and $page->render($options) should be enought to fit the needs here.

Do you need this in the Backend or for the Frontend. There's the ProField Multiplier, which you could use on the frondend as well. But for the frontend I would rather suggest using a simple base markup (some wrapper and inputfield) and clone this via javascript, while using your suggested variant to store things.

I'll later take a look at it, but this could benefit of an inputfield selector. In my use cases I wouldn't hide these tabs for all pages.

Pagefields are one way connections, so there's no way for "get me all areas which are at least in one pagefield", but there is "get me all pages of those pagetables". $artists = $pages->find("template=artist"); $used_areas = new PageArray(); foreach($artists as $artist){ $used_areas->import($artist->areas); //areas is the pageTable; } $used_areas = $used_areas->unique(); // Remove duplicates Edit: or this: foreach($pages->find("template=area_page") as $a) { if($pages->get("template=artist, areas=$a")->id){ // Found a page with this area so it's used } }

Ryan had some issues with renewing the certificate last week. But it should be resolved by now.

Just as I'm in the means to build a separate directory for bugfixes, where I just paste in disposable processwire installations. Really great. Will certainly take a look at it later. I can also see this very useful for setting up base installations in a more flexible way than siteprofiles.

For me this is throwing a more detailed error. But this still should not happen, as the php selection should override all the other selectionmodes. "Session: Error saving field "page" - Page 1045 is not valid for page (Page 1045 does not have required parent 1044)" P.S. I'm ultimately for not changing anything on field settings, because they are after all set up in any way for a reason. Edit: Found the culprit in InputfieldPage.module if($field->findPagesCode) { // TODO: we don't currently validate these } if($field->parent_id && $field->parent_id != $page->parent_id) { //Checks parent even though it shouldn't } I'll open an issue over at GitHub.

There are people using that much pages (https://processwire.com/talk/topic/9336-need-help-deleting-an-empty-field-from-a-template-with-2-million-pages/?hl=%2Bmillion+%2Bfield) and the only thing that does not automatically scale for that much pages are files/images. I can't recall where I've read about it, but basicly it's a filesystem limitation, which lets folders only have a certain amount of subfolders/items. ProcessWire needs to be set to use multiple site/assets/files/ folders to prevent a "overflow" of the standart single folder.

ProcessWire's internal access management has nothing to do with your htaccess settings. The rewrite base is only needed so that pretty urls are correctly transformed to parameters which processwire can understand, nothing more. The inherited access you mentioned means, that your current page inherits the access management of the root page. This page has the template "home" and therefore you can change who can access the current page in the settings of this template. Now to your problem: Do other pages work as expected? What exactly do you mean by "line of tabs"? What does the link look like, which takes you to the wrong page?

I don't think it's possible to use the module directly as it depends on form input data, but you could certainly just use the code from the module and modify it to your own extends.

I don't like the interface of Piwik. It feels kinda clunky compared to GA. But with our german privacy protection laws it's just more convenient to use Piwik instead.

That only partially true. ProcessTemplate::executeRename handles the whole rename process and is therefore called to generate the confirm form and to process it afterwards which should be what you want to hook. Pages::saveReady would not work as templates are not pages.

Just use this in the beginning of your templates. if(!$user->isLoggedin()) $session->redirect("/index.html");

You could change this by removing the "permanant" line from the modules config.