Soma

Lol Front-page? Ok Hope the concept is nice as it allows for simple setup and use html or markdown. I added module to directory and created a new thread. Im on mobile so too lazy to link to now.

Template Notes Adds a "Help" tab to pages for notes and instructions on the current template used. You can add content by simply putting a html or markdown file in /site/templates/notes/ the module will automatically load that file if it finds one and adds a "Help" tab to the page edit form. Name the files using the template name. You can use html or markdown to write the help text. - /site/templates/notes/[tplname].html - /site/templates/notes/[tplname].md To style the content you can specify a custom css file url you add to the module settings. http://modules.processwire.com/modules/template-notes/ https://github.com/somatonic/TemplateNotes This module was quickly written after seeing a wish-list request by Joss http://processwire.com/talk/topic/5016-help-tab-for-template/

There you go https://github.com/somatonic/TemplateNotes

If you give me another 10 minutes I got something for you...

Ehrm, but you'll need some sort of module anyway . To have a field read only there's no special module required. But what you want there's no way to do it without additional coding and that's a good example for a simple module. Template Decorator does allow this and many more: http://modules.processwire.com/modules/template-decorator/ It is not for full essays but just a short description of what this "template" does that shows at the top of the content tab. The module would also be a perfect reference for how to do what you want.

No problem maba, we are all only humans. As said, simply updating PW wouldn't do anything what you mention. I've run so many updates and rollbacks of PW and never experienced anything like that. It would be also good to know what you did update, from what to what version. Also sometimes not sure what you mean with updating, or installing as you don't tell "what". The bug in ModulesManager only ever happened if you uninstall MM and reinstall it.

I have a hard time to understand what you saying with all the problem you got. Updating PW (means replacing /wire/ folder only) does nothing you mentioned like loosing processes for admin pages or problems with ModulesManager. Now that we are on ModulesManager. As Ryan says I'm not sure what the problem is for your install, but looks a lot like a memory or max execution time for scripts, which is a php setting. I never experienced any issues like you mention so I can't really see what's happening. Surely removing other modules in this case wouldn't help or do anything related to that particular issue with ModulesManager.

I'm not sure what about the cache file of ModulesManager. It only checks for assets and modules folder to be writeable, but cache should already be writeable. After all the cache folder gets created by PW (php) when installing. So only thing I can imagine is some permission issue on your server. Maybe you have created or uploaded the folder with ftp and it conflicts with php owner rights. Hard to say but all possible. For the missing process: Looking again at the ModulesManager install, uninstall methods, there's definately a bug when uninstalling the module (never done that really ) The setup/modulesmanager admin page won't get deleted but should. After installing it again it finds the still existing admin page and doesn't assign a process of course. Thanks for mentioning, I will fix this later.

No, with WordPress

I think this should work but you can also do $user->user_app->remove($page);

Thanks Martijn. I can't see that notice here, I guess php version matters? Somehow the $value in some cases is still an array and my lazy method to get and render the settings may not account for all possible settings there is for different fields. I'm not sure it is gone now that some changes were made. I pushed another update to 1.0.6 - added settings toggle support for template field - there's even more settings being shown now for fields Thanks

Just pushed an update to 1.0.5 to fix issues once again (!) - updated to account for current new development on admin theme - some optimizations - kinda fixed an issue with the new LanguageFieldsTabs. - It was getting overlayed by the tabs. Also the LanguageFieldTabs alters the field content via JS and appends the tabs, which results in my Helper links being at the top instead at the bottom! Annoying and not possible to fix from my side, but if LanguageFieldTabs.js would prepend() the tabs instead of append() it would be better. I don't see an easy way to account for this issue from my side, maybe someone has an good idea. - but for now it's on top of those fields using language tabs. - added new feature to toggle a layer when clicking on the little gear icon, with some infos on the field settings, which can be useful when developing without going to the field editing screen. There maybe still issues in some cases I haven't tested or thought of. Thanks

I trink maybe imageTags.title%=$q if the tags are pages, not? And also maybe add the template of the image pages to the selector just to make it more explicit.

This is mostly just for Ryan, but anyway. Something I asked myself a couple times and I think others too. The module repository on PW site shows a Last Updated date on a module page which seems to be always updated randomly or not sure how. Thing is it has nothing to do with the module being updated nor the module page itself. Could we have this date being only updated when there's a new version? For example my ModulesManager shows "November 21, 2013" and I haven't done anything to it. Confusing. Further it looks like the date coming from the json feed is different than the one on the module repository page. For ModulesManager it shows me 2013/11/22 . I think it has to do with caching, but definately something that we should look into. Thanks

maybe better use $u and not $user if ($u = $session->login($username, $pass)) { echo "logged in $u->name"; } nm screw it

It will save fields but you can't publish page.

I asked me the same some time ago. Reason being that it would have no id yet which is required by some fields like images. They're stored for the page and uploaded using ajax.

I'm not sure why it's not working for you without seeing the whole. Make sure you have trailing slash disabled for the template and language are active etc.

Thanks Ryan, that's what I did but not using $_POST[name] but with $field->attr("value") and it was already stripped out. Lots of confusion. Testing around and looking at database revealed the real issue. It's that there's a "stripTags" option setting for textarea fields. It looks like that was checked before it was changed to TinyMCE. Changing it to TinyMCE hides that setting but is still save in the config in DB. So kinda mean. That also explains why changing it to multilanguage field and back to textarea makes it work again. So it's a bug that must be harder to find than fix. It was tricky because I wasn't aware that much that there's a stiptags option on textarea fields that is hidden once Wywiwyg is enabled.