LostKobrakai

There's already a topic about exactly this somewhere in the forum. I'm on mobile, so you'd need to look for it by yourself. Basicly the answer is language alternate fields.

The site profile exporter should still work as expected. The core architecture of ProcessWire hasn't changed in that time. It's not exactly meant to be a backup, but it produces a site profile that's installable by processwire like the default profiles you chose from while installing it the first time. The most drastic difference to a backup would be, that the old users are not there after a siteprofile installation. For the database backup, there's currently no documentation about it other than the comments in the core files. But take a look at the modules "Database Backups" and "Cronjob Database Backup" if you're curious. But really there isn't much more besides the functions you mentioned.

That's why all of us suggest doing updates on dev environments. If there are problems just wait till they are sorted out. Just do not update live sites and expect it to work every time. Additionally it's still the development version that most of us use, so it's natural that problems can arise, but if so report them and sooner or later they will be sorted out. As said before there's currently no need to update for other reasons than access to new features. Regarding userinputs: Sanitizing them is what you need to do no matter which cms you use. As soon as you do implement functions where users can directly input data you need to make sure it's not harmful data. So if you're for example using the core comments systems that's already implemented, but with ProcessWire's nature of encouraging to build own systems you need to be aware of the potential of malicious input from users. For example anywhere you accept data from forms or from parts of the url you need to consider that a user could abuse those points of access to inject own logic.

The urlSegment way would work like this: www.example.com/url/to/page/filename.jpg There the "filename.jpg" is the url segment and you could output/return the right file in the template of the page, in this case the one under "/url/to/page/".

No problem. We all have to do this besides work. I'm curious, if the db dump will show any differences, as it seems to work for me with your siteprofile and therefore the same database (besides the user profile).

You're missing the mandatory sleepValue() and wakeupValue() functions. These are responsable for makeing the objects data available to the database functions and for combining the data from the database to the field object.

Nope, LanguageTabs are a different kind of animal. The fieldsets mentioned are WireTabs.

While the current dev version allows for user templates to be distributed over multiple parents it's still a quite new feature and therefore can have some quirks. As every user of your site is already automatically represented as "guest" it's really not that safer to do anything. Users are users, what makes them a security issue is how much permissions you give them. What I can understand is, that mixing both types in a single list by default is maybe not the best, but with the new lister view it's easy to adapt this to only show registered members / only admins. With ListerPro it should even be possible to devide this in two different preselected lists.

Maybe this would also be from interest: https://github.com/LostKobrakai/InputfieldPageDependentSelect

Maybe have a look at the chmod of the php files. This could be an issue as you say other files work.

The second part is just copied from the current inputfields.js file. Sure you run the latest dev?

Isn't this automated by now? Never had any noticable delay for this activation.

At best one doesn't even send rendered markup via ajax which would mean you could easily swap the class on the client. In your case, how about using json in a small version like so: <script type="text/javascript"> if(myconfig == undefined) var myconfig = { "title": <?php echo $page->title; ?> }; else myconfig = { "title": <?php echo $page->title; ?> }; </script> Inline it to your ajax response and use the infos by your javascript after the ajax request is done.

You can't have multiple translatable strings in one line. With this being said, why don't you use normal fields for that. This does look like content and not static words.

If not use this: $path = wire('config')->paths->templates . "includes/…";

Please do first look at the Edit part. I seems like the script adds the alternative "0" as value for unchecked checkboxes to the checked ones as well. Could you please add the consoleLog statement in the inputfields.js: if(($field.attr('type') == 'checkbox' || $field.attr('type') == 'radio') && !$field.is(":checked")) { // @todo this part will no longer work with multi-checkbox/radio fields consoleLog("*** Added 0 as alternative ***"); values[1] = '0'; } If this prints the line for both unchecked and checked states than we at least know where it's not working correctly. Edit: Looking at your logs again, maybe this isn't the issue, but more likely the checkbox returning a value of 1 even if it's unchecked. Could you also please test if this lines are correctly setting value to null. // value of the dependency field we are checking (if not already populated above) if (value === null) { if($field.attr('type') == 'checkbox') { value = $field.is(":checked") ? $field.val() : null; } else { value = $field.val(); } }

So the logic seems to be working. Could you please inspect one of those two fields? The wrapping li.Inputfield of the field should have "display:none" and "display:block" as inline style and switch between them as you change the checkbox.

To make this fully clear. The implode function you're using is a ProcessWire specific implementation of the php function. The php version does only work on arrays and the array has to be passed into the function as parameter. What you're using is a method of the WireArray class, which mimics a lot of the array features, but adds lot more to it. That's why the syntax is different and therefore the php docs wouldn't help to much.

It's sad to say, but even your siteprofile does work as expected for me. The only difference left would be the php version you're running.

Then please to to /wire/templates-admin/scripts/inputfields.js and enable DebugMode on top there. Also make sure debug mode in /site/config.php is enabled. This will print out lots of information about the dependency management in your console. If this does not help by itself please post the relevant parts here.

There were some changes recently to implement support for OR-Selectors. Could you please check if your console does log any javascript errors? I've just checked it in a installation of mine and it's working, so maybe there's something interfering. To check the suggestion of horst just inspect the checkbox with the dev tools to see it's "checked" value. <input type="checkbox" id="Inputfield_checkbox" class="FieldtypeCheckbox" name="checkbox" value="1">

Maybe this could help you debugging. $mr = wire('user')->user_mr; $p = new Page(); $p->template = "basic-page"; $p->parent = $pages->get("/"); $p->title = $mr; // See what value $mr has // $p->title = $mr == "4702" ? "Is 4702" : "Is not 4702"; // alternative $pa = new PageArray(); $pa->import($p); return $pa;

Maybe we need to make "Search ProcessWire" a part of the documentation

To your question: It would certainly be possible to route your urls to the default paths. But as long as you'd need php for this routing it would introduce additional overhead to images, which already are the big bottleneck of websites just by file size. I don't know if you could do this by .htaccess rewrites only. Should really depend on how flexible it should be. With php involved you could for example use the urlSegments to make images available as part of the page they are on, where the base url is the page's url and the trailing filename would be evaluated as urlSegment.

You got this a little bit wrong: The $config urls are not there to set something, they just get you the url, so you don't need to write it (and it's more prove to changes, even if they aren't likely). It's not shorter, but you can just care about the path relative to the templates folder. <link rel="stylesheet" type="text/css" href="site/templates/styles/style.css"> <!-- becomes this --> <link rel="stylesheet" type="text/css" href="<?php echo $config->urls->templates; ?>styles/style.css"> Your proposed images path won't be possible as files are saved in page-specific folders, therefore the page's id as one folder. Otherwise you can't have two pages with files named the same. This is a needed behavior to make file uploads scale as well as everything else in ProcessWire. To elaborate more about why it's not a suggested idea to move these locations around: - Everything outside of the site/ folder is part of the processwire core and is therefore not save from potential updates. Therefore anything specific to your site should be inside this folder. It's save there and additionally easily moved to another installation and easy to backup without adding the cms files itself. - The .htaccess file does incorporate quite a few rules (depending on the location of files) to make it as secure as it is. - There's an option to secure files of hidden / unpublished pages from direct access, which is dependent on the path files are stored in. - There's an option to have images distributed over multiple folders, so it scales even beyond some filesystem limitations (only needed for sites with thousands of pages, but still), which is also dependent on a fixed location. - The folder structure make a lot of sense, even if it may seem verbose if one looks only at the single entity "uploaded files".