Soma

To build such tools is time consuming. And we all can't afford the time and energy and knowledge, like you too, to build them. Also it's nothing to do with admin theme per se, as those workflow and bulk editing things wouldn't be able to be build solely there. It would have to be built by modules. And I create already quite a lot of helper modules and theme that help out a lot and has improved my working with PW alot already. Ajax editing isn't possible within PW, as there's fields that need a lot more than just content (TinyMCE, Page etc) and need additional script and configurations. At least it isn't something easy. @raydale. But I have something else for you which is fun http://processwire.com/talk/topic/2380-fancy-admin-mode/ :) Regarding workflow and bulk editing. I see many possibilities creating custom edit modules and I think time will come where these appear (as my WIP). It's just we all haven't got the time needed to do everything within the short amount of time PW is out. Also I don't see all this workflows and bulk editing everybody requests as something that important, as you can easily open 2-3 tabs and do that without going back and forth clicking in the menus, and I know other (Ryan) also works this way. So having a flow that allows to edit everything from everything wouldn't be much of a time saver as I see it. Further the API can be used to create a lot of pages or field or templates quickly. DAMN STUPID FORUM SOFTWARE!!! It's getting worse and worse.... sorry

There's some issues with floated elements in widget content (already mentioned this couple times) 1. I have two floated buttons and I need to hack the container to be able to avoid collapsing. 2. When floating the inputfield buttons, the margin on the button is adding and you see the background color when hovering, instead the margin should be on the wrapping <a>. So simply doing this in my css to float the buttons #MC_NewsletterPreview div a { float: left; } And get this: Instead I have to do this to fix both issues with it, which is not really nice. Overflow hidden on container is a solution I would avoid. #MC_NewsletterPreview div a { float: left; margin: 0 1em 0 0; /* add margin */ } #MC_NewsletterPreview .ui-widget-content .ui-button{ margin: 0 0 0 0; /* fix hover background color issue */ } #MC_NewsletterPreview .ui-widget-content{ overflow: hidden; /* fix floated content issue */ } To get this #id's Last but not least. When I have a inputfield "title" it adds an #title id to it. But the admin page when editing a page has already a #title for the page title above form. This should be changed to something like "#pw_title" to avoid issues. Stupid me, I just have to set a different ID, forgot it's not set by PW but by my code. So not a real problem just something to keep in mind.

Just updated to 1.0.3 with some fix and new feature. fixed issue with template edit link added support for repeater fields http://modules.processwire.com/modules/helper-field-links/

This is a perfect way and I think the only one, even ProcessPageEdit uses it. If you output in your module $this->page you'll get the id of the admin page and not the edited one. So the GET id is there to know what page. I think there's other way to get to the page but it will end in the same call somewhere anyway. To check process your on in admin try $this->process and you'll get ProcessPageEdit as it's the process module running. So get the page and set it to the inpufield module with $this->page = $this->pages->get($this->input->get->id); Is simple enough and will always work in this context. Then use it as usual if(!$this->page->editable()){...}

Ah now, my local XAMPP has symlink to htdocs. Using wire('config')->paths->root it works. But doing this doesn't. wire("config")->paths->templates = wire("config")->paths->root; $somepage = wire("pages")->get("/about/what/"); echo $somepage->render(); But setting the paths->templates in config.php does work even with $_SEVER['DOCUMENT_ROOT']. $config->paths->templates = $_SERVER['DOCUMENT_ROOT'] . "/";

So you mean this should work? $home = wire("pages")->get("/about/what/"); $home->template->filename = $_SERVER['DOCUMENT_ROOT'] . "/basic-page.php"; echo $home->render();

You'll laugh but there's been such cases where people do swap prices in a shop and get away with it.

That's what I've tried in all variants and it doesn't work for some reason. $somepage->template->filename = '/path/to/file.php'; doesn't get recognized in a bootstrap.

Haha, yes in this case not a real problem maybe. But I see it rather as the "most stupid thing" to create and publish such a script to the not so aware folks out there in the first place. Which obviously has a security problem and will be used by common "have no idea" users. And I'm not sure about what the laws are if a user can order a thing for 0.01 and you at the end have to deliver it for that price.

Yeah, when you use LanguageLocalizedURL module you should mentioned that as it makes it quite different. The page find method works, but maybe you'd need to set the parent path correctly. Glad you figured.

Have you tried using find? $products = $page->find("parent=/produtos/, limit=3"); Or is there any other page->find with limit happening in your templates? This could inteferer with this and should use "start=0" in selector I think.

Theres no need for curly brackets for variables. And I don't understand the question. What does not work?

Welcome pcreact I'm not sure why you want to do this, but I did a quick test and I also can't get it to overwrite after a bootstrap. It seems the config after bootstrap is somehow not recognized when rendering a page after that and already set to the system. I tried with a hook or set the template file before rendering but couldn't get it to work. But I am sure there's something I'm missing.

I changed my code above example: It's not needed to each them just: $("#menu span:empty").remove();

If your doing the opposite you better just do this: array ('item_tpl' => '<a href="{url}"><span class="nav_extra_title">{nav_extra_title}</span>{title}</a>') Then use this to hide empty spans $("#menu span:empty").remove(); I'm not sure, but most commonly you execute the script before dom even loaded. So if the script is like this in the header it will never work. A technique is to execute it after dom load. $(document).ready(function(){ // your code }); Or short method $(function(){ // your code }); Otherwise I don't know.

Hmm, took me 2 seconds to hack it, and enter my own price... which then get's submitted to paypal. Not a solution I would take serious.

Rally nice what you have done to the blog profile, hardly recognize it

It's not possible to do conditional markup generation. So you're maybe better off building you're menu with your own code. Which is quite simple. Only workaround I see is using JS to generate it. array('item_tpl' => '<a href="{url}" data-extratitle="{extra_title}">{title}</a>') Then use jquery. $('#menu a[data-extratitle!=""]').each(function(){ $(this).prepend($("<span class='nav_extra_title'>"+$(this).data('extratitle')+"</span>")); });

But then it will be visible until you check it and save it again...

Theres a like button by the way ;-)

Thats why i sugested the checkbox. Or you can add a check in your menu code with $page->viewable(). That should ommit pages with no template file.

A page with no template also is not viewable and has no publish mechanismus. If you want to still have that you could add a publish checkbox and use that in queries assuming you have the data somewhere output. Otherwise you could give it a template for that matter.

Repeater shouldn't be excessively used and nested. It's not built for that use and will likely cause some problems. I thougth Ryan decided to put a restriction already to prevent nested repeaters. Anyhow there seems to be a function going nested wild and is limited per some setting on server or php I think.

Delete the entry in the modules table and you should be fine.

It seems all profiles that are exported and installed this way suffer from this problem. You have to create the folders manually. I already created a new profile using the latest PW and the issue remains. Maybe Ryan knows more about and how it could be fixed. So it's not a problem of this profile but the Profile Exporter and how it all works. So I can't really do anything to fix it. It's not possible to give permissions to folders that are in the repository.