Soma

You can move a page into another parent, but that parent has to be open.

Works fine in repeaters for language fields. Any more infos to help reproduce this?

What is this number for the category you'r importing? In PW a category would be best handled as a page, so it could be the ID of that page. Then you make references using the page field. Common scenario is to import/create categories first then use their id's to import data.

I use Sublime Text.

Can't tell a problem without understanding exactly what you're doing on "other pages". If you reference a page it will always have the actual data from that page, unless you have a cache on these pages.

A page field always saves the page id of the selected page, there's no way to save another value. After all it's just a relation with from page id to page id.

Maybe adding something like that would benefit to allow adding scripts and styles before all admin ones. Of course admin templates would have to implement it aswell as long as it's "hardcoded" in admin template. Which in the long run makes it hard to change those parts and every iteration (already were a couple in admin templates) all admin templates suffer from missing something. I could even see go as far as modularize the output so there would be a core module that would be hookable to add scripts and styles more precisely. Just thinking loud.

No I don't know of a better solution. But I don't really see a problem much as the script and styles gets added after the admin main.css... One other solution would be to add an additional script and styles foreach to the admin default.php after the ones already there. <?php foreach($config->cpScripts->unique() as $file) echo "\n\t<script type='text/javascript' src='$file'></script>"; ?> And load scripts and styles to a new config array: $this->config->cpStyles = new FilenameArray; $this->config->cpScripts = new FilenameArray; Then add scripts and styles to that. This way you could also add styles and script even from within the template too.

Sorry but I can't reproduce this. Image are always rendered the same order as in the admin. It's not possible to add another text field unless you modify the module (make a copy to site folder and rename all relevant names and add more text fields) or use ImagesManager where you can have as much custom fields a page can hold.

Maybe in this case nothing to worry about, but I find the Process modules a great thing also because it's a actual Class you can create execute functions and hook into them or load stuff from one module to another. Now there's only one ProcessModuleAdminPages and one execute.

Ah you get that error on front-end! Yeah then it's because you overwrite $config->scripts. Yeah the module does also get init'd on front-end as all autoload module does, but the hooks also get executed. I just updated the module now to not add the hooks when on front-end.

What if you want to hook a admin page like this or use $this->process to identify what admin page you're on?

According to your error this code fails $this->config->scripts->add($this->config->urls->AdminHotKeys . "jquery.hotkeys.js?v={$version}"); Strange ad it makes absolutely no sense. There's nothing wrong here and it's a common code used in many places in ProcessWire and I have no idea why it would fail there. I tested to make sure it works in all PW versions. The error says that $this->config->scripts isn't an object, but then PW admin wouldn't work at all, and I see no indication AdminHotKeys screws that up. What PW version do you have installed and what PHP version, any other 3party modules? Even if a module is uninstalled it will get parsed by php and any error will show. If you want to get rid of a module you ahve to remove it completely.

Where is the censor filter when you need him.

Welcome Billy! If you're looking for a forum this might be a choice http://fluxbb.org/ easy and lightweight software. There's no real forum module for PW (yet except the one from apeisa) but it's also because there's many good out there full featured.

Do I miss something obvious? If so I'm sorry Ryan. Any abstractation can be reverted. If you really want or need to just run a script that converts it back the same way PageLinkAbstractor does.

You'll have to get access to the form builder support forum. This is recently a post by Ryan on a recent update.

Sorry, was a lttle longer edit after first post.

Of course it doesn't get the result because the first url is wrong... that's what Ryan mentioned, you have a /data/ folder inside assets? Which is missing in the first url /site/assets/list-details.json http://mysite.com/site/assets/data/list-details.json So it should be then: /site/assets/data/list-details.json which will work fine. To go further if you want to make it always have the correct url even if you move PW folder to a subfolder you would use the $config->urls->assets in front of data folder. $filepath = $config->urls->assets . "data/list-details.json"; If you want to have it in your JScript as a variable you could use a json object to have access to it in js. Somewhere in your pages html <head> before your angular js script: <?php $jsconfig = array('assets' => $config->urls->assets); ?> <script> var config = <?php echo json_encode($jsconfig);?>; </script> Then use it in your angularjs like this: $http.get( config.assets + 'data/list-details.json').success(.... PW is using this same technique in the admin.

Maybe simpler to do this: if($page->is("name=slideshow18|slideshow28|slideshow38|slideshow88")){ // page has one if the names } Or if it doesn't matter what number if($page->is("name^=slideshow")){ // page name starts with slideshow }

The best way is to avoid having PW in subfolder and on root on production. Search replace the sql dump is maybe most simple. And there's also this module http://processwire.com/talk/topic/236-module-page-link-abstractor/

.. what hook did you use? ;-)

Have you deleted the sessions? What PW version? Any modules installed?

You could use hashs //set window.location.hash = someid; // get hash = window.location.hash; and use $(window).on("hashchange", function(e){ var hash = window.location.hash; // do what you need }); BBQ might a little overkill for your needs, but you could use the simple hashchange implementation plugin of it.