iWeb - Publisering kun av endrede sider?

[Tiril]

Er det noen som har funnet ut hvordan man kan unngå å måtte publisere hele webstedet på nytt i iWeb for hver enkel oppdatering man gjør når man publiserer til en mappe (og annen server enn .Mac)? Jeg har sett det beskrevet i "bruksanvisningen" et sted at man må være oppmerksom på at det faktisk er det som skjer når man publiserer, men det er jo utrolig tungvint!

Jeg undrer meg på om ikke noen har laget et eller annet for kun å publisere endrede sider til mapper fra iWeb, slik som til .Mac ....
Noen som vet?

Fant forøvrig fram til et program på apple.com som heter Multisite for iWeb, og som gjør det mulig å holde styr på mange ulike websteder som lages i iWeb. Ypperlig . Burde vært innebygd i iWeb.

[csharp]

Prøv med FileZilla. Da kan du huke av for kun endrede filer, eller noe slikt.

[Tiril]

FilleZilla er såvidt jeg kan se, et FTP-program for å laste opp til server. Det trenger jeg ikke. Jeg bruker Fetch og den fungerer utmerket, også til å laste opp bare endrede sider.

Det jeg tenker på, er selve publiseringen fra iWeb til mappe. Der må alt gammelt overskrives, og dermed må jo alt sammen også lastes opp i neste omgang med Fetch eller FilleZilla e.l. til server. Tungvint, og det tar tid når man begynner å få mange bilder på webstedet sitt og bredbandet ikke er alt for bredt.

Er det en funksjon i iWeb jeg har oversett, - eller finnes det en programsnutt som kan hjelpe..?

[csharp]

Aha, leste spørsmålet litt dårlig.

Men jeg mener da bestemt at iWeb selv publiserer kun de endrede filene dersom du publiserer til mappe, eller til .Mac, dersom du ikke velger "Publiser alt" eller hva det nå heter (det er to valg på menyen der).


Problemet har "som regel" vært å publisere til en annen server enn .Mac uten å publisere alt, og jeg trodde det var det som var problemet og dermed foreslo jeg FileZilla.

[larsf]

Når iWeb publiserer til folder, publiserer den alle filer som tilhører det eller de nettstedene du har laget i en og samme .sites2 pakke. .sites2 filtypen er den typen iWeb 2 oppretter for originalpakken av filer som inngår i web-prosjektet ditt. Hvis du ikke har endret navnet på den, heter den Domain.sites2 Den kan ligge på forskjellige steder, men i utgangspunkt legger vel iWeb denne i brukerbiblioteket ditt, og pakker alle web-stedene du har i samme .sites2 fil. (.sites2 er typen for iWeb 2.)

Programmer som Multisite for iWeb o.l. kan hjelpe til å øke funksjonaliteten til iWeb, men når det gjelder ett behov, som det å splitte arbeidet til forskjellige nettsteder i forskjellige domain-pakker (.sites2-filer), er det en omvei, som øker risikoen for feil, oppdateringstrøbbel o.l. Apple har en oppskrift på dette som er svært enkel og uten de problemer som slike programmer kan skape: Du lager simpelthen forskjellige Domain.sites2-filer (kopier Domain.sites2 fila i Finder), en for hvert nettsted du arbeider med, og legger dem hvor du vil i filsystemet. Du kan også gi dem det navnet du vil, slik at du unngår det generiske Domain-navnet. (Jeg er ikke sikker på om du fortsatt må beholde en Domain.sites2 fil i biblioteket for innhold som skal publiseres på .mac, siden jeg ikke bruker dette.)

En slik splitt av pakkene for originalfiler til iWeb-nettsteder, gjør i alle fall at du unngår å publisere alle nettsteder du bruker iWeb til hver gang du skal publisere en endring i ett av dem. Men du må fortsatt publisere alle filer til det nettstedet du har i en og samme .sites2-fil, og laste folderen for dette opp til serveren din over ftp el.l. med et ftp-program. Ftp-program som Transmit har funksjoner for synkronisering av filer mellom din maskin og server, men selv har jeg ikke sett noen forskjell i å bruke den og å foreta en full opplasting. Jeg tror det har å gjøre med at iWeb berører alle filer når du publiserer til folder, og at dette har å gjøre med bruken av xml-filer i et prosjekt.

[Tiril]

Takk for utfyllende info. Var ikke klar over muligheten til å splitte i Finder. Det øker fleksibiliteten litt selv om det ikke løser det problemet jeg omtalte. iWeb endrer farge på filer og websteder som endres fra blått til rødt. Når man publiserer endrer fargen tilbake igjen til blått. Dette fungerer imidlertid bare ved publisering til .Mac. Ved publisering til mappe, står alt fortsatt med rød farge. Går ut fra at Apple har brukt tid på å legge inn begrensningene for å øke bruken av .Mac, men synes de skyter seg litt(!) i foten her, iallefall så lenge .Mac er så tregt som nå. At iWeb overskriver samtlige filer ved hver ny publisering er kanskje betryggende for å sikre rett formatering, men det er tungvint når filmengde og -størrelse øker. iWeb er vel strengt tatt laget for de enkle publiseringsoppgavene, men det er jo et relativt ungt program, så man kan kanskje håpe på forbedringer..

[larsf]

Det stemmer nok at iWeb er laget for enkle publiseringsoppgaver, men et moderne web-sted er likevel ingen enkel sak. Filene henger sammen med hverandre, og iWeb bruker css-koder (som er den vanlige metoden i mer avansert web-design) for å kontrollere ting som farger, plassering på siden o.l. På grunn av at web-lesere ikke holder seg til html og css-standardene på samme måte, forsøker iWeb også å hjelpe til med å sikre at sidene blir riktig fremstilt i forskjellige miljøer, på Mac, Windows og med forskjellige nettlesere. Måten dette skjer på, er ganske kompleks. Hvis du laster opp bare enkelte filer som du tror er blitt oppdatert når du har gjort endringer, må du passe på at du tar høyde for de filene som inneholder f.eks. css-koder til de sidene du har gjort endringer på. Disse kodene kan være innbakt i html-filen til hver enkelt side og / eller i css-filer som legges i folderne for elementer til sidene. Hvor kodene blir skrevet tror jeg også avhenger litt av hvordan du går frem når du redigerer sidene i iWeb, hvis du leker og jukser med fonter, f.eks., utenom de oppsatte malene, skal du helst vite litt om hva web-leserne som mottar stoffet ditt vil oppføre seg.

Det er fullt mulig å redigere disse manuelt, hvis du vet hva du gjør. Men poenget med iWeb er jo at det gjør det mulig for brukere som ikke har peiling på kode å produsere web-sider som holder, og da må du nok regne med at det er lett å bryte med forutsetningene om du forsøker deg på snarveier som iWeb ikke er ment for.