The 1.9 theme and template system
#43
(2021-10-30, 02:55 PM)Devilshakerz Wrote: In addition to current/, I also used latest/, [stampable], and directories with placeholder names. These refer to the same concept: a directory that generally contains the most recent code, and may be renamed to indicate a specific version (i.e. be stamped in a v* format compatible with version_compare(), becoming an archive, or versioned directory). TheĀ  name of that original directory would indicate how it's used, and/or what happens to it.

Why would we allow a bunch of different names for the same concept? Isn't that unnecessarily confusing matters, especially since it means that more than one of these differently-named but conceptually identical directories might exist? Why not simply accept only the one name, current/, for the one concept? In any case: what different uses/happenings do the various different names indicate?

(2021-10-30, 02:55 PM)Devilshakerz Wrote: We expect these directories to contain theme-related information, so they would be found directly under:
  • inc/themes/[theme codename]/ (all data of a theme, possibly excluding the manifest file)
  • inc/plugins/[plugin codename]/theme/ (all theme resources and modification instructions of a plugin)

References to other extensions are not expected to use this concept, i.e. if inc/plugin/[plugin codename]/theme/[plugin version]/theme-changes/[theme codename]/[theme version] directories contain resources & modification instructions relevant to a given theme, [theme version] always indicate a specific version of that theme.

Fair enough.

(2021-10-30, 02:55 PM)Devilshakerz Wrote:
Quote:I think you might be suggesting here that automatically keeping current/ and its archived version in sync is prone to errors, or am I misunderstanding?

Yes, in that the system may query the two directories - initially expected to be equivalent - interchangeably, and when their contents differ, it may be problematic.

I agree. This is problematic. We should avoid redundancy where possible. I threw it out as a possible alternative solution, but I don't think that it's ultimately the best solution (I've indicated what I think the best solution is).

(2021-10-30, 02:55 PM)Devilshakerz Wrote:
Quote:Similarly to my immediately previous comment: the approach I've suggested seems to avert the need for code like this in that the current/ directory would never be duplicated via an archived version directory - that corresponding version directory would only be created under controlled circumstances in which its contents are being replaced by the upload of a new current directory with a new version in its manifest file.

Do you see any problems with this approach?

We'd still need some logic to resolve explicit versions to current/, if they happen to be most recent (otherwise - the archives).

You're right. However, this seems to me to be a very minor problem, especially since most of the time the system will want to pull out the latest theme resource, and can then simply pull it out of the current/ directory.

Are there any other problems that you envisage with this approach?

(2021-10-30, 02:55 PM)Devilshakerz Wrote: During development of a new version of an extension, the version number can be changed (incremented, e.g. from 1.0.0 to 1.0.1) by the developer when the extension is already active.

If the system creates an archive automatically using current/, so that the information about all versions can be queried from archives: a new 1.0.1 archive is made so the mechanism can continue to work, but subsequent changes to current/ (where further 1.0.1 work is saved) would not be copied to the 1.0.1 archive.
In this scenario, the developer would have to continue copying changes to the archive manually so the data can be queried properly (or the other way around, intending to keep the git-friendly directory up to date).

Yes: this, too, I think, makes the "current plus redundant archived version" approach sub-optimal, given my preferred alternative.

(2021-10-30, 02:55 PM)Devilshakerz Wrote: If the system skips archiving for the latest version: the version information may no longer be continuous on the developer's installation, since there was no 1.0.0 archive (because current/ was used instead, and by then it's used as the source for 1.0.1).
In this scenario, the developer would have to create an archive manually before starting work on the next release (which seems like the solution you describe).

Yes, but that's only assuming that the explicitly-versioned directory would ever even be used. As I wrote above, in the vast majority of cases, the system is going to simply be interested in the current (latest) version of the theme.

It seems to me to be a minor price for developers to pay for the otherwise ease-of-use of the "upload a zip to the ACP (or unzipped to the staging directory)" approach.

(2021-10-30, 02:55 PM)Devilshakerz Wrote:
Quote:
(2021-10-26, 01:53 PM)Devilshakerz Wrote: Alternatively to such permanent routing, we can consider:
  • current/ as a temporary override
    Content in current/ directories would override the version directory specified in the manifest (and prevent the system from renaming current/, if that's being done).

    This would still require checking for potential override directories when attempting to fetch data from "archives", but the behavior would be limited to a "development mode".

A temporary override of whatever the latest versioned directory is?

Yes, but we may not need to limit it to the latest version: the system can read the manifest file in the override directory (current/ would then have that role), and queries related to that version would use that directory, rather than the archive.

This seems to me again to be over-complicated and confusing. When would it be useful? I think it is much more useful to be able to rely on current/ being - well, current - rather than standing in for some non-current directory.

(2021-10-30, 02:55 PM)Devilshakerz Wrote: A less I/O-intensive approach could use symlinks, where current/ points to the version archive according to the manifest file.

I considered that approach too, but it seems to me to be fraught with peril. For one, symlinks on Windows (as "shortcuts") don't seem to work so well with web servers. For another, symlinks are difficult (impossible?) to include in zip archives. [Edit: Doing some googling, I see that recent versions of Windows have full UNIX-like support for symlinks over and above "shortcuts", so maybe my criticism is no longer valid for recent Windows versions. I don't use Windows much these days and haven't kept up.]
Reply


Messages In This Thread
The 1.9 theme and template system - by Laird - 2021-04-24, 10:56 PM
RE: The 1.9 theme and template system - by Laird - 2021-04-24, 11:07 PM
RE: The 1.9 theme and template system - by martec - 2021-04-25, 04:09 AM
RE: The 1.9 theme and template system - by martec - 2021-04-25, 06:08 AM
RE: The 1.9 theme and template system - by Laird - 2021-04-25, 09:10 PM
RE: The 1.9 theme and template system - by martec - 2021-04-26, 01:37 AM
RE: The 1.9 theme and template system - by Laird - 2021-05-12, 09:28 AM
RE: The 1.9 theme and template system - by martec - 2021-05-08, 04:35 AM
RE: The 1.9 theme and template system - by martec - 2021-05-10, 05:23 AM
RE: The 1.9 theme and template system - by martec - 2021-05-13, 04:19 AM
RE: The 1.9 theme and template system - by Laird - 2021-07-08, 06:03 PM
RE: The 1.9 theme and template system - by Laird - 2021-07-08, 12:41 PM
RE: The 1.9 theme and template system - by Laird - 2021-07-08, 05:09 PM
RE: The 1.9 theme and template system - by Laird - 2021-07-09, 11:22 AM
RE: The 1.9 theme and template system - by Laird - 2021-10-23, 01:44 PM
RE: The 1.9 theme and template system - by Laird - 2021-10-24, 05:26 AM
RE: The 1.9 theme and template system - by Laird - 2021-10-24, 09:13 AM
RE: The 1.9 theme and template system - by Laird - 2021-10-25, 04:20 AM
RE: The 1.9 theme and template system - by Laird - 2021-10-26, 12:16 AM
RE: The 1.9 theme and template system - by Laird - 2021-10-26, 12:21 PM
RE: The 1.9 theme and template system - by Ben - 2021-10-29, 08:09 AM
RE: The 1.9 theme and template system - by Wazzyl - 2021-10-29, 10:26 AM
RE: The 1.9 theme and template system - by Laird - 2021-10-30, 04:43 AM
RE: The 1.9 theme and template system - by Laird - 2021-10-31, 04:04 AM
RE: The 1.9 theme and template system - by Raion - 2021-11-23, 01:31 AM
RE: The 1.9 theme and template system - by Laird - 2021-11-23, 02:14 AM
RE: The 1.9 theme and template system - by Raion - 2021-11-23, 06:31 PM
RE: The 1.9 theme and template system - by martec - 2022-05-05, 03:36 AM
RE: The 1.9 theme and template system - by Raion - 2022-05-06, 10:23 PM
RE: The 1.9 theme and template system - by martec - 2022-05-07, 12:46 AM
RE: The 1.9 theme and template system - by martec - 2022-05-11, 10:54 PM
RE: The 1.9 theme and template system - by Raion - 2022-05-12, 12:22 AM
RE: The 1.9 theme and template system - by Laird - 2022-05-12, 11:38 AM
RE: The 1.9 theme and template system - by Laird - 2022-05-12, 11:36 AM
RE: The 1.9 theme and template system - by martec - 2022-05-14, 05:40 AM
RE: The 1.9 theme and template system - by Laird - 2022-05-16, 04:39 AM
RE: The 1.9 theme and template system - by martec - 2022-05-16, 12:42 PM
RE: The 1.9 theme and template system - by Laird - 2022-05-16, 01:22 PM

Forum Jump:


Users browsing this thread: 1 Guest(s)