LPagery vs Magic Page Plugin

LPagery lees ’n CSV- of XLSX-lêer in jou blaaier, wys die kolomme voordat enigiets gestoor word, en behandel elke kolom as ’n plaasvervanger. ’n Google Sheet werk deur middel van ’n skakel, en ’n Radius-bron haal stede rondom ’n ligging op. Elke ry word ’n bladsy, ongeag wat die ry beskryf.

Magic Page se sigbladinvoer aanvaar XLSX, XLS en CSV op die bediener, met elf vaste kolomme in ’n vaste volgorde: term-ID, ligging, breedtegraad, lengtegraad, poskode, streek, distrik, land, aanduiding van groot stad, slug en bevolkingsgrootte. Kolomme vanaf die twaalfde word pasgemaakte velde. ’n Ry is ’n plek, dus pas die datamodel by liggingsbladsye en min anders. Magic Page se hoofdatabron is sy eie liggingsdatabasisse vir 19 lande, wat van die verskaffer afgelaai word. Watter lande ’n lisensie ontsluit, en hoe op datum die data is, is nie in hierdie oorsig geverifieer nie. Geen Google Sheets-invoer is in 7.2 gevind nie.

LPagery sinchroniseer ’n Google Sheet volgens ’n skedule, uurliks by verstek en tot weekliks. Elke lopie laai die sheet af, skep bladsye vir nuwe rye, werk bladsye by waarvan die ry verander het, slaan rye oor wat nie verander het nie, en verwyder bladsye vir verwyderde rye wanneer jy daardie opsie aanskakel. ’n Mislukte ry word weer probeer en ’n mislukte aflaai merk die stel met die fout.

Geen Google Sheets-integrasie is in Magic Page 7.2 gevind nie. Die naaste funksie is die verskaffer se opdateringskanaal vir sy eie liggingsdatabasisse: ’n weeklikse kontrole wys jou wanneer ’n streek ’n nuwer weergawe het, en jy voer die opdatering met die hand uit. Dit dek die verskaffer se liggingsdata en niks wat jy self geskryf het nie.

In LPagery is die sjabloon enige bladsy, plasing of pasgemaakte plasingtipe wat jy reeds het. Jy voeg plekhouers daarby en kies dit in die kontroleskerm. Elke pasgemaakte veld van daardie bladsy word gekopieer met die plekhouers vervang, dus werk bladsybouers wat hul uitleg in plasing-meta stoor via daardie roete, en elf bladsybouers het hul eie adapter daarbo-op. Elke bladsystel het sy eie sjabloon, en ’n stel kan later na ’n ander een gewys word.

Magic Page het een meesterbladsy per webwerf. Dit registreer sy eie plasingtipe, blokkeer ’n tweede plasing sodra een bestaan, en die weergewer gebruik die nuutste een. Die meesterbladsy word in die Classic- of Gutenberg-redigeerder geredigeer. Elementor is die enigste bladsybouer met ’n versoenbaarheidsfilter, en Thrive Architect kry een filter vir sy kortkodes. Divi, Bricks, Oxygen, WPBakery, Beaver Builder, Brizy, Breakdance en SeedProd word nie in 7.2 verwys nie, en pasgemaakte plasingtipes as sjablone is ook nie gevind nie.

LPagery skryf standaard werklike WordPress-bladsye, wat dit Classic Mode noem. Live Mode is die alternatief: elke bladsy is ’n klein stukkie en die inhoud word vanaf die sjabloon weergegee wanneer iemand dit oopmaak, sodat ’n sjabloonverandering op elke lewendige bladsy sigbaar is sodra jy stoor. Jy kan ’n bladsy of ’n hele stel tussen die twee modusse wissel. Classic-bladsye behou hul inhoud wanneer die inprop gedeaktiveer word; lewendige bladsye moet eers na Classic omgeskakel word.

Magic Page is standaard virtueel. Niks word in die plasingsdatabasis geskryf nie: een meesterplasing word onder elke ligging-URL bedien en die ligging se data word met elke versoek daarin vervang. ’n Ligging word as ’n taksonomieterm gestoor, met een meta-ry per kolom. Deur die meesterbladsy te redigeer, verander elke URL met die volgende versoek, wat die inprop se strukturele voordeel is. Export to Static Pages is die fisiese model waarvoor jy moet inteken: dit skryf een werklike plasing per ligging, met ’n drupskedule wat die publikasiedatums oor dae versprei.

Twee dinge volg uit die virtuele model. WordPress-soektog vind nie die liggingbladsye nie, omdat slegs die meesterplasing bestaan. En elke bladsyversoek voer ’n afstandnavraag oor die hele liggingstabel uit, dus groei die koste van ’n versoek saam met die aantal liggings; die syfers is onder Scale and limits.

LPagery plaas die rye in ’n tou op jou bediener. ’n Werker verwerk die tou en elke bladsy word in sy eie versoek gegenereer, dus is die PHP-tydlimiet van toepassing op een bladsy en nooit op die hele lopie nie. Jy kan die oortjie sluit, later terugkom en die vordering onder Manage sien. Mislukte rye word weer probeer met ’n pouse tussen pogings, en ’n lopie sonder vordering vir tien minute word as vasgeloop aangedui, sodat jy weet WP-Cron loop nie.

Magic Page het geen tou en geen bedienerkantse taakverwerker nie. Elke lang bewerking (die databasisinstallasie, die sigbladinvoer, die statiese uitvoer en die opruiming van ongebruikte liggings) is ’n lus van administrateurversoeke wat deur jou blaaiersoortjie aangedryf word. Elke versoek verhoog sy eie tydlimiet na 60 sekondes en verwerk een bondel. Deur die oortjie te sluit, eindig die lopie. Die statiese uitvoer en die databasisinstallasie behou hul posisie op die bediener, sodat jy dit vanaf dieselfde skerm kan hervat. Die sigbladinvoer behou sy posisie slegs in die blaaier, dus begin ’n geslote oortjie van voor af en voer rye wat reeds geskryf is ’n tweede keer in.

Ons CSV met 300 rye het 61.5 sekondes deur Magic Page se invoerder geneem in twee bondels, omdat die invoerder die hele sigblad met elke bondel weer oopmaak en ontleed.

Wanneer jy ’n gewysigde lêer oplaai, laat LPagery jou toe om bestaande bladsye te skep, te ignoreer of op te dateer. ’n Bladsy word slegs opgedateer wanneer sy ry of sy instellings verander het. As iemand ’n gegenereerde bladsy met die hand geredigeer het, merk LPagery dit tydens die stoor op en laat die bladsy onveranderd, tensy jy kies om handmatige wysigings te oorskryf. Verwyderde rye kan hul bladsye tydens ’n sinkronisering uitvee.

Magic Page werk liggings by deur die sigblad weer in te voer. ’n Ry met ’n term-ID werk daardie ligging by en oorskryf sy naam, slug en elke veld; ’n ry daarsonder skep ’n nuwe ligging. Rye wat in die sigblad ontbreek, word onveranderd gelaat, en verwydering is ’n aparte hulpmiddel, Delete Unused Locations, wat elke ligging buite die meesterbladsy se radius permanent uitvee in bondels van 20. Bespeuring van handmatige wysigings is nie in 7.2 gevind nie: ’n ligging wat met die hand geredigeer is, word deur die volgende invoer oorskryf, en uitgevoerde statiese bladsye word in plek opgedateer, dus gaan handmatige wysigings daaraan verlore. Sjabloonveranderinge werk andersom: omdat bladsye virtueel is, bereik ’n wysiging aan die meesterbladsy elke URL sonder enige lopie.

Geen van die betaalde planne beperk die aantal bladsye nie. LPagery se werker verwerk by verstek 1 000 rye per siklus en verdeel ’n groot oplading in dele, sodat ’n klein oplaaibeperking op die gasheer dit nie blokkeer nie. Magic Page voer 100 tot 400 rye per versoek in en installeer verskafferdata 50 rye op ’n slag. Twee limiete is spesifiek tot Magic Page. ’n Bouproses kan hoogstens rondom agt radius-sentrums tegelyk werk; verdere liggings moet een vir een gekies word. En die koste van ’n bladsyversoek groei saam met die liggingstabel, omdat elke versoek afstande oor alle liggings bereken: in ons laboratorium het 25 bladsyversoeke 4,2 sekondes geneem wanneer dit warm was by 309 liggings, en 10 sekondes wanneer dit warm was by 5 010 liggings, waar een versoek ’n hoogtepunt van 56 MB PHP-geheue bereik het. ’n LPagery-regstreekse bladsy kos een bestaanskontrole plus een geïndekseerde opsoekaksie per plasing, ongeag die grootte van die stel.

LPagery vervang plekhouers in die titel, slak, uittreksel, inhoud en elke pasgemaakte veld, sodat die velde van Yoast SEO, Rank Math en SEOPress vanaf die sjabloon deur daardie enkele roete ingevul word, terwyl All in One SEO sy eie hanteerder kry omdat dit data in sy eie tabel stoor. Beeldkolomme kry ’n lêernaam en alt-teks per bladsy. LPagery genereer geen kanonieke merker of eie werfkaart nie: dit laat albei aan jou SEO-inprop oor, en die bladsye is normale plasings wat in die kern- en SEO-inprop-werfk שarte verskyn.

Magic Page is sterker wat plaaslike SEO-uitset betref. Dit genereer LocalBusiness JSON-LD per ligging met adres, koördinate, openingstye en skakels na sosiale media, plus ses geo-metamerkers. Titel, beskrywing en sleutelwoorde word deur substitusie verwerk, maar daar is geen slakpatroon nie: die URL is een globale voorvoegsel plus die liggingslak. Yoast SEO en All in One SEO is geïntegreer; Rank Math, SEOPress, The SEO Framework en Slim SEO is nie in 7.2 gevind nie. Een beeld per meesterbladsy dien as die SEO-beeld, en beeldkolomme per ligging is nie gevind nie. Twee gedragspatrone beïnvloed die hele werf. Die inprop verwyder WordPress se kern-kanonieke merker met elke voorkantversoek en genereer slegs sy eie een wanneer die meesterbladsy daarvoor kies, wat by verstek afgeskakel is. En met die eerste laai van ’n admin-bladsy stel dit die permalink-struktuur op /%postname%/ sonder om te vra. Sy eie werfkaart is by verstek afgeskakel; in ons laboratorium het een ligging met ’n spasie in sy slak veroorsaak dat daardie werfkaart vir elke besoeker ’n fout terugstuur totdat die ligging verwyder is.

Magic Page het die ryker sjabloontaal, en dit is rondom liggings gebou. ’n [if]-blok met [elseif] en [else] wys inhoud vir een ligging, streek, provinsie of hoofstad-aanduiding, of vir ’n benoemde Location Set. [random chance="40"] behou of verwyder ’n blok met daardie waarskynlikheid, en die uitslag word per ligging gestoor. XFields is benoemde veranderlikes met een verstekwaarde en oorheersingswaardes per ligging, wat gebruik word om telefoonnommers en resensie-uittreksels per ligging te skep. [cities] lys die naaste ander liggings volgens afstand, en kan volgens radius, provinsie en hoofstad-aanduiding gefiltreer word, terwyl [map] ’n Google Map met jou eie API-sleutel insluit. ’n Spintax-uitdrukking kan een keer benoem en deur die hele werf hergebruik word.

LPagery het geen voorwaardelike blokke, geweegde ewekansige blokke of afstandsordening nie. As ’n sin slegs vir sekere rye moet verskyn, plaas jy dit in sy eie kolom en laat jy die sel vir die ander rye leeg; ’n telefoonnommer per ry is ook net ’n kolom. Plekhouers kan genestel word. Views bou ’n gestileerde lys of rooster van verwante bladsye op elke bladsy, wat volgens ’n gedeelde kolomwaarde gekoppel en volgens naam, datum of ’n kolom van jou keuse georden word. Kolomme kan ook die outeur, ouerbladsy, status en taksonomieterme van elke bladsy instel.

Spintax werk in albei, en albei hou die gekose variant stabiel oor opdaterings heen: LPagery stoor ’n saadwaarde per bladsy, terwyl Magic Page die gekose indeks per ligging kas. Magic Page kan ook mettertyd spintax op ’n gedeelte van die bladsye herrol deur sy daaglikse cron, wat by verstek afgeskakel is.

LPagery genereer KI-teks en -beelde per ry in die LPagery-toepassing en stuur die voltooide bladsystel na die inprop. Jy kies die teksmodel per webwerf uit ses opsies oor OpenAI en Google heen. Beeldopdragte bevat styl, formaat, stemming en jou handelsmerkkleure, en teksopdragte is in meer as twintig tale beskikbaar, gekies volgens jou webwerf se land. Elke betaalde lisensie kry ’n maandelikse kredietaanvulling, dus hoef jy geen API-sleutel op te stel nie.

Geen KI-funksie is in Magic Page 7.2 gevind nie. Die enigste derdeparty-sleutels waarvoor die inprop vra, is sy lisensiesleutel en ’n Google Maps-sleutel, en die verskaffer se funksieblad lys ook geen KI-vermoë nie.

LPagery se syfers kom uit die WordPress.org-inpropgids op die verifikasiedatum. Magic Page Plugin is nie op WordPress.org gelys nie, dus is daar geen installasietelling, gradering of opdateringsdatum uit daardie bron nie. Die nuutste inproplêer in die 7.2-zip is gedateer 2024-10-04, en die inpropkop vermeld geen getoets-tot-weergawe nie.

Slegs LPagery het twee weergawe-modusse met omskakeling in albei rigtings, virtuele beeld-URL's wat een beeldlêer onder 'n ander naam per bladsy bedien, 'n stilstandkontrole vir onaktiewe WP-Cron, Google Sheets-sinkronisering, AI-kolomme met krediete, en 'n invoerpad vir plekhouers wat vir die Multiple Pages Generator-inprop geskryf is.

Slegs Magic Page het afstand as 'n eersteklas-konsep, Location Sets, XFields, 'n drupfunksie wat liggings oor 'n konfigureerbare aantal dae vrystel, Export to Static Pages met verspreide publikasiedatums, uitvoer van die hele webwerf as statiese HTML, PDF-weergawe deur die verskaffer se API, 'n liggingssoektog aan die voorkant, en 'n Google Maps-inbedkode per ligging. Die verskaffer se liggingdatabasisse vir 19 lande is nie in hierdie oorsig geverifieer nie.

Ons het LPagery se administrasie met 'n lêer van vyf rye deurgegaan en getel wat 'n nuwe gebruiker moet leer en klik voordat die eerste bladsy aktief is. LPagery vereis drie konsepte (sjabloonbladsy, plekhouer, bronlêer) en een vereiste instelling, die sjabloon. Alles anders het 'n verstekwaarde. Die eerste bladsy was aktief ná ses klikke op drie skerms.

Magic Page se administrasiepad kon nie in dieselfde laboratorium gemeet word nie, omdat geen lisensiesleutel daar aktief was nie en die hoofbladsy-redigeerder een benodig. Uit die kode en skerms wat ons nagegaan het: die konsepte is 'n hoofbladsy, liggings, radius, Location Sets, XFields en 'n stel kortkodes; die instellingskerm bevat 29 kontroles op een bladsy, waarvan 15 geen etiket het wat 'n skermleser kan gebruik nie; en die Magic Page-lys vertoon elke liggingsterm inlyn in een tabelsel, sonder 'n limiet.