Macrura

right - actually i'm not sure if i have that... i tend to overwrite my dev versions with the latest when i download them... it's not a huge deal except for the fact that i was using fontawesome on these custom pages and that no longer works.. i did try copying the admin-templates from the wire into the site, directory to see if i could get the fontawesome to work.. guess i either need to deal with it for the time being or revert to the old theme by uninstalling that admin theme module

ooh - thanks Manfred62 - yeah let me see if i can uninstall that; thing is that i do like the new admin theme etc.. but might need to wait for diogo to update the admin custom pages to work with this new setup!

with the new way the admin theme is structured as a module, it seems that if you are using the admin custom pages module, the module isn't aware of the locations of the new admin theme files, so it still uses the old default theme; so i'm just wondering - how can I either switch the admin theme to the classic old theme, or has anyone figured out how to make the admin custom pages module work with the latest dev, using admin theme module.. TIA

I'm using pete's example code here, but i added a lot of stuff for my use case, but it's basically this: http://processwire.com/talk/topic/1648-ok-to-change-page-name-path-after-save/?p=15232

@pete - many thanks for your example; i used your code and made a module, and this works really well, eliminates that first screen and auto-generates the page name as the id; i'm also using another example you posted to then build the name from various fields, once the user clicks save..

@diogo - this is more of a status report - using the latest dev, where the admin theme is now module, the custom pages still use the old default admin theme.. cheers, marc

that's exactly how i did the Ohm Speakers store, and also another shop i'm working on; i like this approach the best if the child products have a lot of their own images, and individual data/specs. if it were a simpler product then repeaters would probably work ok and maybe be easier for the end user to understand..

in general unless you want to build an extended file inputfield, you should use repeaters; each repeater would contain the file upload (single file deference), and any other fields you need. while you don't get the convenience of multi drag and drop, this is the easiest plug-and-play way to have as many fields grouped with your file field as you need. for example we have a site with audio and each audio file is in a repeater with fields like "artist", "composer", "purchase link" etc; so when we build the audio player on the front end we can also sort by artist or composer, as well as use those fields to feed to the player (without having to rely on ID3 tags)

many thanks - will test soon!

nice

you could import from a csv into pages if you're just using them as selects for example you could store all of the data in 1 text field.. and then use php to make the list into options you could also consider storing in a static file, xml or json, or xml/json in a field it really depends on what you need to do with this data

@pwired - great find... i will check this out for the next smaller ecommerce integration, using s-f-p

if there were a simple paypal payment integration it might cover a lot of smaller site needs!

foxycart is not self hosted, but you can use a cname record to have the cart look like it is on your domain. the whole reason to use FC is so you don't need to host anything. it is true that you could use the shop-for-processwire as a cart and then at checkout FC allows you to pass all of those items to their cart and proceed to their checkout page, so if you design it all right, it could be completely seamless, and then you would have the ease and low cost of your processwire site, and the security and robustness of the foxycart system; i'm considering that option, namely using the shop for processwire as a pre-cart and then at checkout having the button pass all of the data to the foxy(cart), but haven't tested it yet. reading back the transaction details from the foxycart XML feed to processwire has been solved in this thread http://processwire.com/talk/topic/4997-foxycart-xml-datafeed-integration/

@bfd - the page path history was developed to solve that problem, and you should enable it on your site once you go live; http://modules.processwire.com/modules/page-path-history/ prior to going live, when you migrate to the new location you can do a search/replace in the SQL file to fix the paths. you might also look at this: http://modules.processwire.com/modules/page-link-abstractor/

What's wrong with Processwire + Foxycart? Working fine really well for one client of mine and soon to be integrated into another site. from the foxycart site: Use the CMS you already love. FoxyCart is built to complement your own preferred tools, and as such can be integrated into anything, whether it’s hardcoded HTML, a dynamic CMS, or a custom framework. Use the best tools for each specific job, not a one-size-fits-all system.

@horst - Ryan is away till 12/22 - maybe try PMing him

Really nice

Lato rules

cool - and don't be afraid to rtrim your $demos... <?php echo "("; $gewt = $pages->find("template=addProject, projectManager=$f"); $out = ''; foreach($gewt as $demos) { $out .= $demos->profName->title . ", "; } echo rtrim($out, ", "); echo ")";

Hi Enver, so you're simply trying to output a field that is on a 'related' page to the selected user, but where that select takes place is on the project, not on the user. so this is also pretty simple, as you foreach through the users, you also have to do a page search (using api and selector) to find the page(s) that have the current user selected. so within the foreach do another $pages->get("template=addProject, profName=$f"); or something like that - if there are multiples then you would do $pages->find, and then you'll end up with a page array so you'll do a nested loop

assuming that you already know about the pages field having to be a single page (not a page array) if you are outputting them like you are (and not foreaching through the variable as if it is an array), then there's no reason why this shouldn't work: <?php $findmylisting = $pages->find("id!=40, roles=superuser, template=user, sort=name"); foreach($findmylisting as $f) { $stateAdd = $pages->get("$f->state")->title; echo '<p>'; echo $f->fullname; echo $stateAdd; echo $f->resourceType; echo $f->ProfName; echo '</p>'; } again i really don't get your naming convention here, it seems quite counter-intuitive, meaning that I cannot easily discern looking at your code what any of the variables are intended to represent; so this is a coding style sort of issue and at least in my experience and reading about general coding and PHP programming, you should really be aiming for readable code, not just the formatting but also what things represent semantically. you should also add comments, like <?php // $foo is a page select which gets the selectable pages from the template bar and returns a single page blah blah blah obviously we have separated each variable out onto it's own line so that you can comment each one out to precicely find which one is causing your error, and then experiment from there with why you are getting the error. We have clearly determined the cause of the error that you posted, which was because you were using a non-existant field name.

hey Enver - i guess the issue is again that i can't seem to follow the logic of your templates/fields relations as well as how those are interacting with users as well asd page selects; Are you trying to output user info on the frontend? i think you might need to use check_access=0 see the cheatsheet for more info

awesome! Lastest Posts = Latest Posts (?)

totally agree with Craig here...!