Soma

I was also thinking about this the other day while developing modules. I'm not sure about the best way but this sounds like a good way I already did in my projects (/site/libs/). Though I'm not sure what is if the one module uses the same lib as an other one, but needs an different version of it?

I experienced some strange behavior when editing templates. Once you do a refresh when editing it can screw up the fields added to it completely. Last time I had to delete the template completely, because it got fields added like "role" which can't be deleted once added! Really strange, it might not related to this issue here but thought I could mention it here.

I tend to use the breadcrumb that will open the tree again. Or sometimes use cmd click (mac) to open in new tab. Also useful I found my DataTable module that enables to edit many pages faster as I open them in a modal. But of course this would also help and I think easy to do with a module.

I would take this route... Make the "container" pages you're saying having a template "redirect", with only a single page field "redirect_page" with pagelistSelectMultiple input Then have the template file code: $session->redirect($page->redirect_page->url); or how about "redirect-to-firstchild". $session->redirect($page->children->first()->url); Edit: Another option would be to use javascript to set urls of first level to "#".

If the source URL is relative it must be relative to the requested page. Nothing special, either relative or absolute. It can get quite difficult with relative paths and not so flexible. Make sure you're the paths from the root of the web dir are correct. Paste the path into the browser and see if the body_templates.js file can be loaded Try inspecting with chrome tools or firebug if it's failing to load the file Not sure what else Edit: Also check if you're in a subdir (not web root). Then you would have to adapt the paths in the body_templates.js file with that subdir included. /subdir/site/...

Hah! That happens regularely including myself. The behavior (if set right) I think is correct. ( After all it's surely possible I missed something while testing ) So if you ommit pages by saying "parent!=1002", the page 1002 will have no "has_children" as there's no children to be rendered in the menu. It will only append the "has_children" class to items that really have children show up in the navigation at some point, cutting of at the max_levels or if excluded by a selector. Only side effect of it I noticed recently is if you have two navigation (top, sidebar) and set the top to max_levels 1, and render the rest of the navigation on a separate call in the sidebar. The top level won't have "has_children" class appended. But I don't know if that would make sense, needed or even possible with this apporoach.

Thanks diogo for the testing! Glad it works out for you too

renobird, can you give me more to chew? Code you use for the navigation, and the output? Feel free to send me pm if you don't want to post here. I think you mean "has_children" because there's no "has_parent"

Bill I still don't get what this would do any different than simply doing this: $keys = explode("|", $pagearray); Except that this module will load on every page load. Bear with me, as I'm maybe missing the obvious. Dumb me, now I get it! It's not only about id's

I encourage you to try the other thread, as it does the same and even more and will be replace this. I just figured a better way to include templates too. It's possible that you have PW installed in a subdir? Try the path in your browser directly, it should load the file.

I just updated with a new version 3. First post download. I added root path to all setting that start with a "/". And also the third-party settings will now work if PW is in a subfolder from the root. Other related files you create in the /site/ folder you'll have to make sure you use include the subfolder. Files like body_templates.js you could make a php file and add root path to any template paths.

The content.css does add the the root subfolder to the path already. I'll do the same with the third-party plugin settings (as we can assume they're values are always a path) As for when you want to add additional resources via the Additional textarea (to overwrite settings) it hard to detect (maybe not) if theres a path from the root, as it can be anything (true,false,"string"). So if you want to add something there like ui.css you would have to add the subfolder to the path. This is in the body_templates.js you would usually have to create yourself. .. Ahhh... already edited! Glad you figured it out.

Yes as you said it makes a difference because the path /site/tinymce/plugins/codemagic/editor_plugin.js hence the "/" in the beginning is absolute from the web root. You should adjust the config string to have the real path /subfolder/site/...

you don't happen to have pw installed in a subfolder? can you copy that url and add it in the browser to see if it can load the file?

Well it seems not. I can reproduce this if I change the folder to 774 for example it fails to load. 775 works normally as it should. Is that on a server or locally? Edit: I also downloaded the archive and installed it on my local server. Works well. On my server too. On another PW site I'm working on too. Not sure what's going on but looks like a permission problem.

Diogo, I can't say without seeing more or having any error, or browser infos, firebug maybe? It doesn't work with anything or random characters. The effort is mainly having it configurable even more than it is now. I don't want to get as far as creating a module configuration, as I also don't see why. It maybe possible, but would complicate things even more.

I'm not really sure, but the restriction is for direct access in the browser by visitors... not on the server scripts. Still there seems to be an issue with permission I guess. Anyone else?

It works well here. Have you downloaded the test2? The first archive I attached was wrong. Have you put all in the right place? There sould be a textarea "Third-party Settings" if you got the right one. Try clearing cache. Try to find in firebug or alike if it fails loading anything... I don't understand. There's no module settings. It's configured all in the field settings under "input" tab on the last fieldset. There was recently a update already that ryan did to have content.css outside wire folder. This takes the same approach just goes a little further.

I tested this Pete, It works! If you add this in the field additional settings. editor_css : /site/tinymce/themes/cirkuit/ui.css skin : cirkuit You can even use this with current TinyMCE in PW already. BUT it, as I said above, TinyMCE is still trying to load the skin from the core TinyMCE and gets 404. It still works but don't know a way around that.

Unfortunately this doesn't work. You can add those to the config in the setting, and it will load it. But problem is the "skin" option needs to be set to "cirkuit" too to work. And this will make it want to load the theme from the core tinymce folder... content_css is a different shoe and already configurable and can be placed outside. This is used to style the content in the Wysiwyg. Which in current PW works well.

No, but I'm sure it's a permission problem with ftp user vs apache user. Try set it to 0777. Otherwise you should contact your hosting staff. Also I'm currently working on getting more options to TinyMCE. Might wanna test this?

But you know my main update with this is to use templates (html snippets) not the editor theme. I don't care that much about how it looks, as long as it works. I don't see currently a way to do this. Edit: The only thing would be to get Ryan to include the "cirkuit" skin in the distribution.

Pete, I didn't find a way to overwrite the themes/skin path via config. But the custom config section, allows you to add a line skin : cirkuit This will overwrite the default in PW. All you need to do is upload the "cirkuit" folder. If anyone knows a way around this, I glady add that support.

Sorry, just recognized that I attached wrong InputfieldTinyMCE folder! I just updated the download in the first post. @pete, I'm not sure what would be required, but I'll have a look. I used to use the "silver" skin_variant in my admin theme. Never used cirkuit.

I just tested adding a second third-party plugin "codemagic". It works! Though you have to additionally add the "tiny_mce_popup.js" from tinymce-3.4.7 folder into the "/site/tinymce/" folder to work correctly. Edit: Holy cow, first time using codemagic, what a cool tool!