Leaderboard

HelperFieldLinks Just got a new module working that is only visible to superusers, and is handy for when developing a site, or investigate someone elses. 1. It adds a shortcut link to all fields on page in the backend. The link name equals the field name, so on very large complex sites with lots of fields, it can help to quickly see what name the field has. 2. It also adds a shortcut to the used template (in the template select field under "Settings" tab). They appear on bottom right corner of the field. Any suggestions for a better module name and general feedback is welcome. ProcessWire Modules Directory: http://modules.proce...er-field-links/ Direct github download: https://github.com/s...elperFieldLinks

I tried to integrate parts of another site with ProcessWire today, and quickly gave up, as my existing (older) site has a bunch of classes in the global namespace that collide with some very generic class-names in ProcessWire: Database, Config, Session, Page and so forth. Would you consider introducing support for namespaces? Perhaps in ProcessWire 3.0, as clearly this would break backwards compatibility with the current API. Simply placing PW classes in a vendor-namespace (e.g. "wire") would probably be sufficient to avoid 99% of collisions. I think it would be great if PW-modules followed the "{vendor}\{package}" namespace convention for modules, as this eliminates practically all namespace collisions. Both conventions are compliant with the PSR-1 recommendation - though vendor-name is the minimum required, but I think that's fine for the framework itself. A "smart" IDE like PHP Storm could probably refactor most of the codebase to use namespace more or less automatically. If you're interested, I also have a script somewhere that rewrites entire codebases to namespaces, picks up folder-names and maps those to namespaces as configured. (it's not complete, but would probably get you roughly 971/4% of the way...)

I have the next version ready. I just need to export the profile and double check it all works. I hope to be able to post it later today after getting through some client work.

Any modules that extend: Inputfield, Process or ModuleJS will auto-load their CSS/JS files if they have the same name as the module and appear in the same directory. However, in order for that to work, their init() method has to be called. So if your module extends one of those, and has an init() method, then make sure to call the parent init() method: public function init() { parent::init(); // ... then your code }

http://www.vetsnet.co.uk/ Formerly done in Joomla 1.5, I have just finished migrating the site to PW 2.2. It uses a couple of modules- MapMarker for geocoding for the map thumbnail links Comments (which was why I was pestering Ryan on GitHub the other day 8) ) Email obfuscator <edit>Broken at the moment, so disabled</edit> It is based on the Skeleton framework and is responsive. I would appreciate some feedback on the design. I wanted it plain and lean, and non-fussy, but have I overdone it?

I'm thinking of using SSHFS (http://fuse.sourceforge.net/sshfs.html) to mount a remote NFS disk and mount it on my frontend servers so they all use the same shared filesserver, I'll let you know how things go

Thanks for the input I think the problem I was having with the htaccess is more to do with the way php executes require_once. I looked at the Comments module to see how php files were included in there and it is the same way I was doing (more or less) so I think I am ok. As for the caching it was a simple matter of passing Twig and auto_reload=true setting to the array when initialising it. This way Twig will regenerate a cache file if the source files are updated. It works perfectly. Would there be any interest here in me attempting to tidy the module up a bit? It still has some hard-coded assumptions which I don't like but since I am new to ProcessWire I'm not sure how to correctly approach them.

Makes sense. In my opinion, breaking backwards compatibility (with modules, as well as with the language itself) in something that should only happen with major releases of any platform. Major releases should target new development, while minor releases should target maintenance and provide an upgrade-path. For major releases, in my experience, providing an upgrade-path is "nice to have", but not "must have", as major upgrades very rarely actually happen in reality. Anyways, I'm sidetracking...

I would like PW to run with MongoDB. Just kidding

Woo! Progress!! I fixed the main bug and it is now working. A couple of limitations so far. No easy way to clear the cache, which is in a bad spot to begin with. Is there any way to integrate Twig's cache with PW's? At the moment I have just made a cache folder under my site/views folder. As the cache needs to be regenerated every time the template.php or twig view files are edited are there any suggestions for making this a simple process? I thought maybe have some url/page/?cache=clear get function? Would this be easy to do? Still have the __DIR__ paths in the module itself. I found out the problem with the $config->urls variables was to do with my .htaccess rewritebase having a ~porl at the beginning. I couldn't find an easy way around it (changing it to /home/porl broke other things so I don't know how else to do this setting. Any ideas?). Apart from that it seems to run brilliantly.

Hi porl, yes, fulltext indexes are available in multiple other DB systems (SQLite, Postgres and InnoDB on MySQL to name a few) and there has been a discussion of this with Ryan. Although I don't see it on the roadmap at the moment, I think that Ryan has commented positively about the possibility of making PW flexible enough to use different DB backends although this might not be as easy as it sounds due to the fact that not all SQL dialects are the same. Just to let people know that I have personally managed to get PW running using the InnoDB engine on MySQL v5.6 with very minimal changes to the PW code. Once MySQL 5.6 goes mainstream in linux distros we will, at least, have the choice of a transactional DB engine for PW.

Sent a new pull request today. Fixed the new url replacing feature in textarealanguage and improved behavior. Now if you insert a link in tinymce, it replaces urls found with the correct localized url for each language value when saving page. I changed the hook to the sleepValue() so it get's saved to db and we're done. No need to add this overhead on frontend too this way. Also added a check to prevent execution on field edit screen. When editing a language textarea with tinymce as inputfield, there were some strange error I have no idea where and why. It was finding a href="./templates/" and showed a selector error although there's no such link... I don't think it need to be executed there anyway so this should be fine.

That looks workable, probably fine for most sites. If I need something more complex, maybe I'll spend more time on this, but for the moment I don't feel like I'm missing anything... I had a chance to really dig in today, and I'm very, very impressed with what I've seen so far!

Ah I got it This post helped me to add the valid attributes ()

You're welcome. Haha, don't hurt yourself please! Just for throwing in when using php "Wire"-tag ( ) short notation the above could also be something like this. <? foreach( $pages->get("/about/")->children() as $pa ) : ?> <h2><?= $pa->title ?></h2> <? if( count( $pa->teasers ) ): ?> <ul> <? foreach( $pa->teasers as $rp ) : ?> <li><?= $rp->element_title ?></li> <? endforeach ?> </ul> <? else: ?> <p>No entries found</p> <? endif ?> <? endforeach ?> (short tags needs to be enabled on server, but only few hostings have it disabled. In near future it will always be enabled in php5.4)

Just as a short note (sites are not much more than standard PW installations) www.grahm-anderson.de (lawyer, responsive layout) www.factoring-pool-mittelstand.de (Factoring means selling bills which are overdue to a bank) The latter uses the redirect url module for relocating old urls and Soma's navigation module. More to come soon.

try this one pagefield.title

Ryan was talking about the URL when you logged in, refering to your "blank" page. Anyway, it looks to me as the id from the url isn't submited by the form. A simple debug "echo $input->get->id;" and commenting out the redirect would show that there's no id. So I'd guess, the form action should contain the id so it gets submited by the url.

So long as the servers can share a common file system (or give that appearance), you should be able to set this up. For instance, your /site/assets/ could be a symlink to a dir on another server. But PW needs to be able to scan this directory for files, open files that are in it, and place new files into it when it needs to. PW uses PHP functions like move_uploaded_file(), copy(), rename(), getimagesize() and others to act upon the files in /site/assets/ as needed, which is why they must be accessible as if they were local.

This is on the list for 2.3, so should be coming soon!